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Abstract 


Distribution of this memo is unlimited. 


This document describes the modifications to OSPF to support version 
(IPv6). The fundamental mechanisms of 

OSPF (flooding, Designated Router (DR) 
Path First (SPF) calculations, etc.) remain unchanged. However, some 


6 of the Internet Protocol 


changes have been necessary, 
semantics between IPv4 and IPv6, 


address size of IPv6. 


election, area support, Short 


either due to changes in protocol 
or simply to handle the increased 
These modifications will necessitate 


incrementing the protocol version from version 2 to version 3.  OSPF 


for IPv6 is also referred to as OSPF version 3 


Changes between OSPF for IPv4, 


described herein include the following. 
been removed from OSPF packets and the basic Link State 


Advertisements (LSAs). 
addresses and prefixes. 


than on a per-IP-subnet basis. 


OSPF Version 2, 
Addressing semantics have 


(OSPFv3). 


and OSPF for IPv6 as 


New LSAs have been created to carry IPv6 


OSPF now runs on a per-link basis rather 
Flooding scope for LSAs has been 


generalized. Authentication has been removed from the OSPF protocol 
and instead relies on IPv6's Authentication Header and Encapsulating 


Security Payload (ESP). 


Even with larger IPv6 addresses, 
almost as compact as those in OSPF for IPv4. 


most packets in OSPF for IPv6 are 
Most fields and packet- 


size limitations present in OSPF for IPv4 have been relaxed. In 
addition, option handling has been made more flexible. 
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All of OSPF for IPv4’s optional capabilities, including demand 
circuit support and Not-So-Stubby Areas (NSSAs), are also supported 
in OSPF for IPv6. 
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Introduction 


This document describes the modifications to OSPF to support version 


6 of the Internet Protocol (IPv6). The fundamental mechanisms of 
OSPF (flooding, Designated Router (DR) election, area support, 
(Shortest Path First) SPF calculations, etc.) remain unchanged. 


However, some changes have been necessary, either due to changes in 
protocol semantics between IPv4 and IPv6, or simply to handle the 
increased address size of IPv6. These modifications will necessitate 
incrementing the protocol version from version 2 to version 3.  OSPF 
for IPv6 is also referred to as OSPF version 3 (OSPFv3). 


This document is organized as follows. Section 2 describes the 
differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6 
(OSPF version 3) in detail. Section 3 describes the difference 
between RFC 2740 and this document. Section 4 provides 
implementation details for the changes. Appendix A gives the OSPF 
for IPv6 packet and Link State Advertisement (LSA) formats. Appendix 
B lists the OSPF architectural constants. Appendix C describes 
configuration parameters. 


1. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC-KEYWORDS]. 


.2. Terminology 


This document attempts to use terms from both the OSPF for IPv4 
specification ([OSPFV2]) and the IPv6 protocol specifications 
([IPV6]). This has produced a mixed result. Most of the terms used 
both by OSPF and IPv6 have roughly the same meaning (e.g., 
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interfaces). However, there are a few conflicts. IPv6 uses "link" 
similarly to IPv4 OSPF’s "subnet" or "network". In this case, we 
have chosen to use IPv6’s "link" terminology. "Link" replaces OSPF’s 


"subnet" and "network" in most places in this document, although 
OSPF's network-LSA remains unchanged (and possibly unfortunately, a 
new link-LSA has also been created). 


The names of some of the OSPF LSAs have also changed. See 
Section 2.8 for details. 


In the context of this document, an OSPF instance is a separate 
protocol instance complete with its own protocol data structures 
(e.g., areas, interfaces, neighbors), link-state database, protocol 
state machines, and protocol processing (e.g., SPF calculation). 


2. Differences from OSPF for IPv4 


Most of the algorithms from OSPF for IPv4 [OSPFV2] have been 
preserved in OSPF for IPv6. However, some changes have been 
necessary, either due to changes in protocol semantics between IPv4 
and IPv6, or simply to handle the increased address size of IPv6. 


The following subsections describe the differences between this 
document and [OSPFV2]. 


2.1. Protocol Processing Per-Link, Not Per-Subnet 


IPv6 uses the term "link" to indicate "a communication facility or 
medium over which nodes can communicate at the link layer" ([IPV6]). 
"Interfaces" connect to links. Multiple IPv6 subnets can be assigned 
to a single link, and two nodes can talk directly over a single link, 
even if they do not share a common IPv6 subnet (IPv6 prefix). 


For this reason, OSPF for IPv6 runs per-link instead of the IPv4 
behavior of per-IP-subnet. The terms "network" and "subnet" used in 
the IPv4 OSPF specification ([OSPFV2]) should generally be replaced 
by link. Likewise, an OSPF interface now connects to a link instead 
of an IP subnet. 


This change affects the receiving of OSPF protocol packets, the 
contents of Hello packets, and the contents of network-LSAs. 


2.2. Removal of Addressing Semantics 
In OSPF for IPv6, addressing semantics have been removed from the 


OSPF protocol packets and the main LSA types, leaving a network- 
protocol-independent core. In particular: 
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o IPv6 addresses are not present in OSPF packets, except in LSA 
payloads carried by the Link State Update packets. See 
Section 2.7 for details. 


o Router-LSAs and network-LSAs no longer contain network addresses, 
but simply express topology information. See Section 2.8 for 
details. 


o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the 
IPv4 size of 32 bits. They can no longer be assigned as (IPv6) 
addresses. 


o Neighboring routers are now always identified by Router ID. 
Previously, they had been identified by an IPv4 address on 
broadcast, NBMA (Non-Broadcast Multi-Access), and point-to- 
multipoint links. 


2.3. Addition of Flooding Scope 
Flooding scope for LSAs has been generalized and is now explicitly 


coded in the LSA's LS type field. There are now three separate 
flooding scopes for LSAs: 


o Link-local scope. LSA is only flooded on the local link and no 
further. Used for the new link-LSA. See Section 4.4.3.8 for 
details. 


o Area scope. LSA is only flooded throughout a single OSPF area. 
Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter- 
area-router-LSAs, and intra-area-prefix-LSAs. 


o AS scope. LSA is flooded throughout the routing domain. Used for 
AS-external-LSAs. A router that originates AS scoped LSAs is 
considered an AS Boundary Router (ASBR) and will set its E-bit in 
router-LSAs for regular areas. 


2.4. Explicit Support for Multiple Instances per Link 


OSPF now supports the ability to run multiple OSPF protocol instances 
on a single link. For example, this may be required on a NAP segment 
shared between several providers. Providers may be supporting 
Separate OSPF routing domains that wish to remain separate even 
though they have one or more physical network segments (i.e., links) 
in common. In OSPF for IPv4, this was supported in a haphazard 
fashion using the authentication fields in the OSPF for IPv4 header. 
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Another use for running multiple OSPF instances is if you want, for 
one reason or another, to have a single link belong to two or more 
OSPF areas. 


Support for multiple protocol instances on a link is accomplished via 
an "Instance ID" contained in the OSPF packet header and OSPF 


interface data structures. Instance ID solely affects the reception 
of OSPF packets and applies to normal OSPF interfaces and virtual 
links. 


2.5. Use of Link-Local Addresses 


IPv6 link-local addresses are for use on a single link, for purposes 
of neighbor discovery, auto-configuration, etc. IPv6 routers do not 
forward IPv6 datagrams having link-local source addresses [IP6ADDR]. 
Link-local unicast addresses are assigned from the IPv6 address range 
FE80/10. 


OSPF for IPv6 assumes that each router has been assigned link-local 
unicast addresses on each of the router’s attached physical links 
[IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets 
are sent using the interface’s associated link-local unicast address 
as the source address. A router learns the link-local addresses of 
all other routers attached to its links and uses these addresses as 
next-hop information during packet forwarding. 


On virtual links, a global scope IPv6 address MUST be used as the 
Source address for OSPF protocol packets. 


Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). 
However, link-local addresses are not allowed in other OSPF LSA 
types. In particular, link-local addresses MUST NOT be advertised in 
inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs 

(Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix- 
LSAs (Section 4.4.3.9). 


2.6. Authentication Changes 


In OSPF for IPv6, authentication has been removed from the OSPF 
protocol. The "AuType" and "Authentication" fields have been removed 
from the OSPF packet header, and all authentication-related fields 
have been removed from the OSPF area and interface data structures. 


When running over IPv6, OSPF relies on the IP Authentication Header 
(see [IPAUTH]) and the IP Encapsulating Security Payload (see 
[IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and 
authentication/confidentiality of routing exchanges. 
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Protection of OSPF packet exchanges against accidental data 
corruption is provided by the standard IPv6 Upper-Layer checksum (as 
described in Section 8.1 of [IPV6]), covering the entire OSPF packet 
and prepended IPv6 pseudo-header (see Appendix A.3.1). 


2.7. Packet Format Changes 


OSPF for IPv6 runs directly over IPv6. Aside from this, all 
addressing semantics have been removed from the OSPF packet headers, 
making it essentially "network-protocol-independent". All addressing 
information is now contained in the various LSA types only. 


In detail, changes in OSPF packet format consist of the following: 
o The OSPF version number has been incremented from 2 to 3. 


o The Options field in Hello packets and Database Description 
packets has been expanded to 24 bits. 


o The Authentication and AuType fields have been removed from the 
OSPF packet header (see Section 2.6). 


o The Hello packet now contains no address information at all. 
Rather, it now includes an Interface ID that the originating 
router has assigned to uniquely identify (among its own 
interfaces) its interface to the link. This Interface ID will be 
used as the network-LSA's Link State ID if the router becomes the 
Designated Router on the link. 


o Two Options bits, the "R-bit" and the "V6-bit", have been added to 
the Options field for processing router-LSAs during the SPF 
calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF 
Speaker can participate in OSPF topology distribution without 
being used to forward transit traffic; this can be used in multi- 
homed hosts that want to participate in the routing protocol. The 
V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF 
Speaker can participate in OSPF topology distribution without 
being used to forward IPv6 datagrams. If the R-bit is set and the 
V6-bit is clear, IPv6 datagrams are not forwarded but datagrams 
belonging to another protocol family may be forwarded. 


o The OSPF packet header now includes an "Instance ID" that allows 


multiple OSPF protocol instances to be run on a single link (see 
Section 2.4). 
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2.8. LSA Format Changes 


All addressing semantics have been removed from the LSA header, 
router-LSAs, and network-LSAs. These two LSAs now describe the 
routing domain's topology in a network-protocol-independent manner. 
New LSAs have been added to distribute IPv6 address information and 
data required for next-hop resolution. The names of some of IPv4's 
LSAs have been changed to be more consistent with each other. 


In detail, changes in LSA format consist of the following: 


o The Options field has been removed from the LSA header, expanded 
to 24 bits, and moved into the body of router-LSAs, network-LSAs, 
inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for 
details. 


o The LSA Type field has been expanded (into the former Options 
Space) to 16 bits, with the upper three bits encoding flooding 
Scope and the handling of unknown LSA types (see Section 2.9). 


o Addresses in LSAs are now expressed as [prefix, prefix length] 
instead of [address, mask] (see Appendix A.4.1). The default 
route is expressed as a prefix with length 0. 


o Router-LSAs and network-LSAs now have no address information and 
are network protocol independent. 


o Router interface information MAY be spread across multiple router- 
LSAs. Receivers MUST concatenate all the router-LSAs originated 
by a given router when running the SPF calculation. 


o A new LSA called the link-LSA has been introduced.  Link-LSAs have 
link-local flooding scope; they are never flooded beyond the link 
with which they are associated.  Link-LSAs have three purposes: 1) 
they provide the router's link-local address to all other routers 
attached to the link, 2) they inform other routers attached to the 
link of a list of IPv6 prefixes to associate with the link, and 3) 
they allow the router to advertise a collection of Options bits to 
associate with the network-LSA that will be originated for the 
link. See Section 4.4.3.8 for details. 


o In IPv4, the router-LSA carries a router's IPv4 interface 
addresses, the IPv4 equivalent of link-local addresses. These are 
only used when calculating next hops during the OSPF routing 
calculation (see Section 16.1.1 of [OSPFV2]), so they do not need 
to be flooded past the local link. Hence, using link-LSAs to 
distribute these addresses is more efficient. Note that link- 
local addresses cannot be learned through the reception of Hellos 
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in all cases. On NBMA links, next-hop routers do not necessarily 


exchange Hellos. Rather, 


these routers learn of each other's 


existence by way of the Designated Router (DR). 


o The Options field in the network LSA is set to the logical OR of 
the Options that each router on the link advertises in its link- 


LSA. 


o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". 
Type-4 summary LSAs have been renamed "inter-area-router-LSAs". 


o The Link State ID in inter- 


area-prefix-LSAs, inter-area-router- 


LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing 
semantics and now serves solely to identify individual pieces of 


the Link State Database. 


All addresses or Router IDs that were 


formerly expressed by the Link State ID are now carried in the LSA 


bodies. 


o Network-LSAs and link-LSAs 


carries additional meaning. 


always the Interface ID of 
being described. For this 


are the only LSAs whose Link State ID 
For these LSAs, the Link State ID is 

the originating router on the link 

reason, network-LSAs and link-LSAs are 


now the only LSAs whose size cannot be limited: a network-LSA MUST 


list all routers connected 


to the link and a link-LSA MUST list 


all of a router's addresses on the link. 


o A new LSA called the intra- 


area-prefix-LSA has been introduced. 


This LSA carries all IPv6 prefix information that in IPv4 is 
included in router-LSAs and network-LSAs. See Section 4.4.3.9 for 


details. 


o Inclusion of a forwarding address or external route tag in AS- 
external-LSAs is now optional. In addition, AS-external-LSAs can 


now reference another LSA, 


for inclusion of additional route 


attributes that are outside the scope of the OSPF protocol. For 
example, this reference could be used to attach BGP path 
attributes to external routes. 


2.9. Handling Unknown LSA Types 


Handling of unknown LSA types 
based on the LS type, unknown 
link-local flooding scope, or 
understood. This behavior is 


has been made more flexible so that, 
LSA types are either treated as having 
are stored and flooded as if they were 
explicitly coded in the LSA Handling 


bit of the link state header’s LS type field (see the U-bit in 


Appendix A.4.2.1). 
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The IPv4 OSPF behavior of simply discarding unknown types is 
unsupported due to the desire to mix router capabilities on a single 
link. Discarding unknown types causes problems when the Designated 
Router supports fewer options than the other routers on the link. 


2.10. Stub/NSSA Area Support 


In OSPF for IPv4, stub and NSSA areas were designed to minimize link- 
state database and routing table sizes for the areas’ internal 
routers. This allows routers with minimal resources to participate 
in even very large OSPF routing domains. 


In OSPF for IPv6, the concept of stub and NSSA areas is retained. In 
IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, 
network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area- 
prefix-LSAs.  NSSA areas are restricted to these types and, of 
course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types 
carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 
summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs. 


2.11. Identifying Neighbors by Router ID 


In OSPF for IPv6, neighboring routers on a given link are always 
identified by their OSPF Router ID. This contrasts with the IPv4 
behavior where neighbors on point-to-point networks and virtual links 
are identified by their Router IDs while neighbors on broadcast, 
NBMA, and point-to-multipoint links are identified by their IPv4 
interface addresses. 


This change affects the reception of OSPF packets (see Section 8.2 of 
[OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the 
reception of Hello packets (Section 10.5 of [OSPFV2]). 


The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. 

3. Differences with RFC 2740 
OSPFv3 implementations based on RFC 2740 will fully interoperate with 
implementations based on this specification. There are, however, 
some protocol additions and changes (all of which are backward 
compatible). 

3.1. Support for Multiple Interfaces on the Same Link 
This protocol feature was only partially specified in the RFC 2740. 
The level of specification was insufficient to implement the feature. 


Section 4.9 specifies the additions and clarifications necessary for 
implementation. They are fully compatible with RFC 2740. 
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3.2. Deprecation of MOSPF for IPv6 


This protocol feature was only partially specified in RFC 2740. The 
level of specification was insufficient to implement the feature. 
There are no known implementations.  Multicast Extensions to OSPF 
(MOSPF) support and its attendant protocol fields have been 
deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, 
Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, 
Appendix A.4.3, Appendix A.4.1.1, and Section 7.1. 


3.3. NSSA Specification 


This protocol feature was only partially specified in RFC 2740. The 
level of specification was insufficient to implement the function. 
This document includes an NSSA specification unique to OSPFv3. This 
Specification coupled with [NSSA] provide sufficient specification 
for implementation. Refer to Section 4.8.5, Appendix A.4.3, 
Appendix A.4.8, and [NSSA]. 


3.4. Stub Area Unknown LSA Flooding Restriction Deprecated 


In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within 
stub and NSSA areas. The text describing this restriction is 
included below. 


However, unlike in IPv4, IPv6 allows LSAs with unrecognized 
LS types to be labeled "Store and flood the LSA, as if type 
understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled 
introduction of such LSAs could cause a stub area's link-state 
database to grow larger than its component routers' capacities. 


To guard against this, the following rule regarding stub areas 
has been established: an LSA whose LS type is unrecognized can 
only be flooded into/throughout a stub area if both a) the LSA 
has area or link-local flooding scope and b) the LSA has U-bit 
set to 0. See Section 3.5 for details. 


This restriction has been deprecated.  OSPFv3 routers will flood link 
and area scope LSAs whose LS type is unrecognized and whose U-bit is 
set to 1 throughout stub and NSSA areas. There are no backward- 
compatibility issues other than OSPFv3 routers still supporting the 
restriction may not propagate newly defined LSA types. 


3.5. Link LSA Suppression 
The LinkLSASuppression interface configuration parameter has been 


added. If LinkLSASuppression is configured for an interface and the 
interface type is not broadcast or NBMA, origination of the link-LSA 
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may be suppressed. The LinkLSASuppression interface configuration 
parameter is described in Appendix C.3. Section 4.8.2 and 
Section 4.4.3.8 were updated to reflect the parameter’s usage. 


3.6. LSA Options and Prefix Options Updates 


The LSA Options and Prefix Options fields have been updated to 
reflect recent protocol additions. Specifically, bits related to 
MOSPF have been deprecated, Options field bits common with OSPFv2 
have been reserved, and the DN-bit has been added to the prefix- 
options. Refer to Appendix A.2 and Appendix A.4.1.1. 


3.7.  IPv6 Site-Local Addresses 
All references to IPv6 site-local addresses have been removed. 
4. Implementation Details 


When going from IPv4 to IPv6, the basic OSPF mechanisms remain 
unchanged from those documented in [OSPFV2]. These mechanisms are 
briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a 
link-state database composed of LSAs and synchronized between 
adjacent routers. Initial synchronization is performed through the 
Database Exchange process, which includes the exchange of Database 
Description, Link State Request, and Link State Update packets. 
Thereafter, database synchronization is maintained via flooding, 
utilizing Link State Update and Link State Acknowledgment packets. 
Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain 
neighbor relationships, as well as to elect Designated Routers and 
Backup Designated Routers on broadcast and NBMA links. The decision 
as to which neighbor relationships become adjacencies, and the basic 
ideas behind inter-area routing, importing external information in 
AS-external-LSAs, and the various routing calculations are also the 
same. 


In particular, the following IPv4 OSPF functionality described in 
[OSPFV2] remains completely unchanged for IPv6: 


o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 
of [OSPFV2], namely: Hello, Database Description, Link State 
Request, Link State Update, and Link State Acknowledgment packets. 
While in some cases (e.g., Hello packets) their format has changed 
somewhat, the functions of the various packet types remain the 
same. 
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o The system requirements for an OSPF implementation remain 
unchanged, although OSPF for IPv6 requires an IPv6 protocol stack 
(from the network layer on down) since it runs directly over the 
IPv6 network layer. 


o The discovery and maintenance of neighbor relationships, and the 


selection and establishment of adjacencies, remain the same. This 
includes election of the Designated Router and Backup Designated 
Router on broadcast and NBMA links. These mechanisms are 


described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2]. 


o The link types (or equivalently, interface types) supported by 
OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, 
point-to-multipoint, and virtual links. 


o The interface state machine, including the list of OSPF interface 
States and events, and the Designated Router and Backup Designated 
Router election algorithm remain unchanged. These are described 
in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2]. 


o The neighbor state machine, including the list of OSPF neighbor 
States and events, remains unchanged. The neighbor state machine 
is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2]. 


o Aging of the link-state database, as well as flushing LSAs from 
the routing domain through the premature aging process, remains 
unchanged from the description in Sections 14 and 14.1 of 
[OSPFV2]. 


However, some OSPF protocol mechanisms have changed as previously 
described in Section 2 herein. These changes are explained in detail 
in the following subsections, making references to the appropriate 
sections of [OSPFV2]. 


The following subsections provide a recipe for turning an IPv4 OSPF 
implementation into an IPv6 OSPF implementation. 


4.1. Protocol Data Structures 


The major OSPF data structures are the same for both IPv4 and IPv6: 
areas, interfaces, neighbors, the link-state database, and the 
routing table. The top-level data structures for IPv6 remain those 
listed in Section 5 of [OSPFV2], with the following modifications: 


o All LSAs with known LS type and AS flooding scope appear in the 
top-level data structure, instead of belonging to a specific area 
or link.  AS-external-LSAs are the only LSAs defined by this 
specification that have AS flooding scope. LSAs with unknown LS 
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type, U-bit set to 1 (flood even when unrecognized), and AS 
flooding scope also appear in the top-level data structure. 


4.1.1. The Area Data Structure 


The IPv6 area data structure contains all elements defined for IPv4 
areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type 
that have area flooding scope are contained in the IPv6 area data 
Structure. This always includes the following LSA types: router- 
LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, 
and intra-area-prefix-LSAs.  LSAs with unknown LS type, U-bit set to 
1 (flood even when unrecognized), and area scope also appear in the 
area data structure.  NSSA-LSAs are also included in an NSSA area's 
data structure. 


4.1.2. The Interface Data Structure 


In OSPF for IPv6, an interface connects a router to a link. The IPv6 
interface structure modifies the IPv4 interface structure (as defined 
in Section 9 of [OSPFV2]) as follows: 


Interface ID 
Every interface is assigned an Interface ID, which uniquely 
identifies the interface with the router. For example, some 
implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) 
as the Interface ID. The Interface ID appears in Hello packets 
sent out the interface, the link-local-LSA originated by the 
router for the attached link, and the router-LSA originated by the 
router-LSA for the associated area. It will also serve as the 
Link State ID for the network-LSA that the router will originate 
for the link if the router is elected Designated Router. 
The Interface ID for a virtual link is independent of the 
Interface ID of the outgoing interface it traverses in the transit 
area. 


Instance ID 
Every interface is assigned an Instance ID. This should default 
to 0. It is only necessary to assign a value other than 0 on 
those links that will contain multiple separate communities of 
OSPF routers. For example, suppose that there are two communities 
of routers on a given ethernet segment that you wish to keep 
separate. 
The first community is assigned an Instance ID of 0 and all the 
routers in the first community will be assigned 0 as the Instance 
ID for interfaces connected to the ethernet segment. An Instance 
ID of 1 is assigned to the other routers' interfaces connected to 
the ethernet segment. The OSPF transmit and receive processing 
(see Section 4.2) will then keep the two communities separate. 
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List of LSAs with link-local scope 
All LSAs with link-local scope and that were originated/flooded on 
the link belong to the interface structure that connects to the 
link. This includes the collection of the link’s link-LSAs. 


IP interface address 
For IPv6, the IPv6 address appearing in the source of OSPF packets 
sent on the interface is almost always a link-local address. The 
one exception is for virtual links that MUST use one of the 
router's own global IPv6 addresses as IP interface address. 


List of link prefixes 
A list of IPv6 prefixes can be configured for the attached link. 
These will be advertised by the router in link-LSAs, so that they 
can be advertised by the link's Designated Router in intra-area- 
prefix-LSAs. 


In OSPF for IPv6, each router interface has a single metric 
representing the cost of sending packets on the interface. In 
addition, OSPF for IPv6 relies on the IP Authentication Header (see 
[IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as 
described in [OSPFV3-AUTH] to ensure integrity and authentication/ 
confidentiality of routing exchanges. For this reason, AuType and 
Authentication key are not associated with IPv6 OSPF interfaces. 


Interface states, events, and the interface state machine remain 
unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of 
[OSPFV2] respectively. The Designated Router and Backup Designated 
Router election algorithm also remains unchanged from the IPv4 
election in Section 9.4 of [OSPFV2]. 


4.1.3. The Neighbor Data Structure 


The neighbor structure performs the same function in both IPv6 and 
IPv4. Namely, it collects all information required to form an 
adjacency between two routers when such an adjacency becomes 
necessary. Each neighbor structure is bound to a single OSPF 


interface. The differences between the IPv6 neighbor structure and 
the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] 
are: 


Neighbor's Interface ID 
The Interface ID that the neighbor advertises in its Hello packets 
must be recorded in the neighbor structure. The router will 
include the neighbor's Interface ID in the router's router-LSA 
when either a) advertising a point-to-point or point-to-multipoint 
link to the neighbor or b) advertising a link to a network where 
the neighbor has become the Designated Router. 
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Neighbor IP address 
The neighbor's IPv6 address contained as the source address in 
OSPF for IPv6 packets. This will be an IPv6 link-local address 
for all link types except virtual links. 


Neighbor's Designated Router 
The neighbor's choice of Designated Router is now encoded as a 
Router ID instead of as an IP address. 


Neighbor's Backup Designated Router 
The neighbor's choice of Backup Designated Router is now encoded 
as a Router ID instead of as an IP address. 


Neighbor states, events, and the neighbor state machine remain 
unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of 
[OSPFV2] respectively. The decision as to which adjacencies to form 
also remains unchanged from the IPv4 logic documented in Section 10.4 
of [OSPFV2]. 


4.2. Protocol Packet Processing 


OSPF for IPv6 runs directly over IPv6's network layer. As such, it 
is encapsulated in one or more IPv6 headers with the Next Header 
field of the immediately encapsulating IPv6 header set to the value 
89. 


As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are 
sent along adjacencies only (with the exception of Hello packets, 
which are used to discover the adjacencies).  OSPF packet types and 
functions are the same in both IPv4 and IPv6, encoded by the Type 
field of the standard OSPF packet header. 


4.2.1. Sending Protocol Packets 
When an IPv6 router sends an OSPF routing protocol packet, it fills 


in the fields of the standard OSPF for IPv6 packet header (see 
Appendix A.3.1) as follows: 


Version # 


Set to 3, the version number of the protocol as documented in this 
Specification. 


Type 


The type of OSPF packet, such as Link State Update or Hello 
packet. 
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Packet length 
The length of the entire OSPF packet in bytes, including the 
standard OSPF packet header. 


Router ID 
The identity of the router itself (who is originating the packet). 


Area ID 
The OSPF area for the interface on which the packet is being sent. 


Instance ID 
The OSPF Instance ID associated with the interface out of which 
the packet is being sent. 


Checksum 
The standard IPv6 Upper-Layer checksum (as described in Section 
8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 
pseudo-header (see Appendix A.3.1). 


Selection of OSPF routing protocol packets’ IPv6 source and 
destination addresses is performed identically to the IPv4 logic in 
Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from 
among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP 
address associated with the other end of the adjacency (which in 
IPv6, for all links except virtual links, is an IPv6 link-local 
address). 


The sending of Link State Request packets and Link State 
Acknowledgment packets remains unchanged from the IPv4 procedures 
documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. 
Sending Hello packets is documented in Section 4.2.1.1, and the 
sending of Database Description packets in Section 4.2.1.2. The 
sending of Link State Update packets is documented in Section 4.5.2. 


4.2.1.1. Sending Hello Packets 


IPv6 changes the way OSPF Hello packets are sent in the following 
ways (compare to Section 9.5 of [OSPFV2]): 


o Before the Hello packet is sent on an interface, the interface's 
Interface ID MUST be copied into the Hello packet. 


o The Hello packet no longer contains an IP network mask since OSPF 
for IPv6 runs per-link instead of per-subnet. 


o The choice of Designated Router and Backup Designated Router is 


now indicated within Hellos by their Router IDs instead of by 
their IP interface addresses. Advertising the Designated Router 
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(or Backup Designated Router) as 0.0.0.0 indicates that the 
Designated Router (or Backup Designated Router) has not yet been 
chosen. 


o The Options field within Hello packets has moved around, getting 
larger in the process. More Options bits are now possible. Those 
that MUST be set correctly in Hello packets are as follows. The 
E-bit is set if and only if the interface attaches to a regular 
area, i.e., not a stub or NSSA area. Similarly, the N-bit is set 
if and only if the interface attaches to an NSSA area (see 
[NSSA]). Finally, the DC-bit is set if and only if the router 
wishes to suppress the sending of future Hellos over the interface 
(see [DEMAND]). Unrecognized bits in the Hello packet’s Options 
field should be cleared. 


Sending Hello packets on NBMA networks proceeds for IPv6 in exactly 
the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2]. 


4.2.1.2. Sending Database Description Packets 


The sending of Database Description packets differs from Section 10.8 
of [OSPFV2] in the following ways: 


o The Options field within Database Description packets has moved 
around, getting larger in the process. More Options bits are now 
possible. Those that MUST be set correctly in Database 
Description packets are as follows. The DC-bit is set if and only 
if the router wishes to suppress the sending of Hellos over the 
interface (see [DEMAND]). Unrecognized bits in the Database 
Description packet’s Options field should be cleared. 


4.2.2. Receiving Protocol Packets 


Whenever a router receives an OSPF protocol packet, it is marked with 
the interface on which it was received. For routers that have 
virtual links configured, it may not be immediately obvious with 
which interface to associate the packet. For example, consider the 
Router RT11 depicted in Figure 6 of [OSPFV2]. If RT11 receives an 
OSPF protocol packet on its interface to Network N8, it may want to 
associate the packet with the interface to Area 2, or with the 
virtual link to Router RT10 (which is part of the backbone). In the 
following, we assume that the packet is initially associated with the 
non-virtual link. 


In order for the packet to be passed to OSPF for processing, the 
following tests must be performed on the encapsulating IPv6 headers: 
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o The packet’s IP destination address MUST be one of the IPv6 
unicast addresses associated with the receiving interface (this 
includes link-local addresses), one of the IPv6 multicast 
addresses AllSPFRouters or AllDRouters, or an IPv6 global address 
(for virtual links). 


o The Next Header field of the immediately encapsulating IPv6 header 
MUST specify the OSPF protocol (89). 


o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the 
IP Encapsulating Security Payloads (see [IPESP]) MUST be processed 
and/or verified to ensure integrity and authentication/ 
confidentiality of OSPF routing exchanges. This is described in 
[OSPFV3-AUTH]. 


After processing the encapsulating IPv6 headers, the OSPF packet 
header is processed. The fields specified in the header must match 
those configured for the receiving OSPFv3 interface. If they do not, 
the packet SHOULD be discarded: 


o The version number field MUST specify protocol version 3. 


o The IPv6 Upper-Layer checksum (as described in Section 8.1 of 
[IPV6]), covering the entire OSPF packet and prepended IPv6 
pseudo-header, must be verified (see Appendix A.3.1). 


o The Area ID and Instance ID found in the OSPF header must be 
verified. If both of the following cases fail, the packet should 
be discarded. The Area ID and Instance ID specified in the header 
must either: 


1. Match one of the Area ID(s) and Interface Instance ID(s) for 
the receiving link. Unlike IPv4, the IPv6 source address is 
not restricted to lie within the same IPv6 subnet as the 


receiving link.  IPv6 OSPF runs per-link instead of per-IP- 
subnet. 
2. Match the backbone area and other criteria for a configured 


virtual link. The receiving router must be an ABR (Area 
Border Router) and the Router ID specified in the packet (the 
Source router) must be the other end of a configured virtual 
link. Additionally, the receiving link must have an OSPFv3 
interface that attaches to the virtual link's configured 
transit area and the Instance ID must match the virtual link's 
Instance ID. If all of these checks succeed, the packet is 
accepted and is associated with the virtual link (and the 
backbone area). 
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o Locally originated packets SHOULD NOT be processed by OSPF except 
for support of multiple interfaces attached to the same link as 
described in Section 4.9. Locally originated packets have a 
Source address equal to one of the router's local addresses. 


o Packets whose IPv6 destination is AllDRouters should only be 
accepted if the state of the receiving OSPFv3 interface is DR or 
Backup (see Section 9.1 [OSPFV2]). 


After header processing, the packet is further processed according to 
its OSPF packet type. OSPF packet types and functions are the same 
for both IPv4 and IPv6. 


If the packet type is Hello, it should then be further processed by 
the Hello packet processing as described in Section 4.2.2.1. All 
other packet types are sent/received only on adjacencies. This means 
that the packet must have been sent by one of the router's active 
neighbors. The neighbor is identified by the Router ID appearing in 
the received packet's OSPF header. Packets not matching any active 
neighbor are discarded. 


The receive processing of Database Description packets, Link State 
Request packets, and Link State Acknowledgment packets is almost 

identical to the IPv4 procedures documented in Sections 10.6, 10.7, 
and 13.7 of [OSPFV2] respectively with the exceptions noted below. 


o LSAs with unknown LS types in Database Description packets that 
have an acceptable flooding scope are processed the same as LSAs 
with known LS types. In OSPFv2 [OSPFV2], these would result in 
the adjacency being brought down with a SequenceMismatch event. 


The receiving of Hello packets is documented in Section 4.2.2.1 and 
the receiving of Link State Update packets is documented in 


Section 4.5.1. 


4.2.2.1. Receiving Hello Packets 


The receive processing of Hello packets differs from Section 10.5 of 
[OSPFV2] in the following ways: 


o On all link types (e.g., broadcast, NBMA, point-to-point, etc.), 
neighbors are identified solely by their OSPF Router ID. For all 
link types except virtual links, the Neighbor IP address is set to 
the IPv6 source address in the IPv6 header of the received OSPF 
Hello packet. 


o There is no longer a Network Mask field in the Hello packet. 
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o The neighbor’s choice of Designated Router and Backup Designated 
Router is now encoded as an OSPF Router ID instead of an IP 
interface address. 


4.3. The Routing table Structure 


The routing table used by OSPF for IPv4 is defined in Section 11 of 
[OSPFV2]. For IPv6, there are analogous routing table entries: there 
are routing table entries for IPv6 address prefixes and also for AS 
boundary routers. The latter routing table entries are only used to 
hold intermediate results during the routing table build process (see 
Section 4.8). 


Also, to hold the intermediate results during the shortest-path 
calculation for each area, there is a separate routing table for each 
area holding the following entries: 


o An entry for each router in the area. Routers are identified by 
their OSPF Router ID. These routing table entries hold the set of 
shortest paths through a given area to a given router, which in 
turn allows calculation of paths to the IPv6 prefixes advertised 
by that router in intra-area-prefix-LSAs. If the router is also 
an area border router, these entries are also used to calculate 
paths for inter-area address prefixes. If in addition the router 
is the other endpoint of a virtual link, the routing table entry 
describes the cost and viability of the virtual link. 


o An entry for each transit link in the area. Transit links have 
associated network-LSAs. Both the transit link and the network- 
LSA are identified by a combination of the Designated Router's 
Interface ID on the link and the Designated Router's OSPF Router 
ID. These routing table entries allow later calculation of paths 
to IP prefixes advertised for the transit link in intra-area- 
prefix-LSAs. 


The fields in the IPv4 OSPF routing table (see Section 11 of 
[OSPFV2]) remain valid for IPv6: optional capabilities (routers 
only), path type, cost, type 2 cost, link state origin, and for each 
of the equal cost paths to the destination, the next-hop and 
advertising routers. 


For IPv6, the link-state origin field in the routing table entry is 
the router-LSA or network-LSA that has directly or indirectly 
produced the routing table entry. For example, if the routing table 
entry describes a route to an IPv6 prefix, the link state origin is 
the router-LSA or network-LSA that is listed in the body of the 
intra-area-prefix-LSA that has produced the route (see 

Appendix A.4.10). 
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4.3.1. Routing Table Lookup 


Routing table lookup (i.e., determining the best matching routing 
table entry during IP forwarding) is the same for IPv6 as for IPv4. 


4.4. Link State Advertisements 


For IPv6, the OSPF LSA header has changed slightly, with the LS type 
field expanding and the Options field being moved into the body of 
appropriate LSAs. Also, the formats of some LSAs have changed 
somewhat (namely, router-LSAs, network-LSAs, AS-external-LSAs, and 
NSSA-LSAs), while the names of other LSAs have been changed (type 3 
and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area- 
router-LSAs respectively) and additional LSAs have been added (link- 
LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been 
removed from the OSPFv2 specification [OSPFV2] and is not encoded 
within OSPF for IPv6's LSAs. 


These changes will be described in detail in the following 
subsections. 


4.4.1. The LSA Header 


In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20-byte 
LSA header. However, the contents of this 20-byte header have 
changed in IPv6. The LS age, Advertising Router, LS Sequence Number, 
LS checksum, and length fields within the LSA header remain 
unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7, 
and A.4.1 of [OSPFV2], respectively. However, the following fields 
have changed for IPv6: 


Options 
The Options field has been removed from the standard 20-byte LSA 
header and moved into the body of router-LSAs, network-LSAs, 


inter-area-router-LSAs, and link-LSAs. The size of the Options 
field has increased from 8 to 24 bits, and some of the bit 
definitions have changed (see Appendix A.2). Additionally, a 


Separate PrefixOptions field, 8 bits in length, is attached to 
each prefix advertised within the body of an LSA. 


LS type 
The size of the LS type field has increased from 8 to 16 bits, 
with high-order bit encoding the handling of unknown types and the 
next two bits encoding flooding scope. See Appendix A.4.2.1 for 
the current coding of the LS type field. 
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Link State ID 
The Link State ID remains at 32 bits in length. However, except 
for network-LSAs and link-LSAs, the Link State ID has shed any 
addressing semantics. For example, an IPv6 router originating 
multiple AS-external-LSAs could start by assigning the first a 
Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2, 
and so on. Instead of the IPv4 behavior of encoding the network 
number within the AS-external-LSA's Link State ID, the IPv6 Link 
State ID simply serves as a way to differentiate multiple LSAs 
originated by the same router. 
For network-LSAs, the Link State ID is set to the Designated 
Router's Interface ID on the link. When a router originates a 
link-LSA for a given link, its Link State ID is set equal to the 
router's Interface ID on the link. 


.2. The Link-State Database 


In IPv6, as in IPv4, individual LSAs are identified by a combination 
of their LS type, Link State ID, and Advertising Router fields. 

Given two instances of an LSA, the most recent instance is determined 
by examining the LSAs' LS sequence number, using LS checksum and LS 
age as tiebreakers (see Section 13.1 of [OSPFV2]). 


In IPv6, the link-state database is split across three separate data 
structures.  LSAs with AS flooding scope are contained within the 
top-level OSPF data structure (see Section 4.1) as long as either 
their LS type is known or their U-bit is 1 (flood even when 
unrecognized); this includes the AS-external-LSAs.  LSAs with area 
flooding scope are contained within the appropriate area structure 
(see Section 4.1.1) as long as either their LS type is known or their 
U-bit is 1 (flood even when unrecognized); this includes router-LSAs, 
network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA- 
LSAs, and intra-area-prefix-LSAs.  LSAs with an unknown LS type, the 
U-bit set to 0, and/or link-local flooding scope are contained within 
the appropriate interface structure (see Section 4.1.2); this 
includes link-LSAs. 


To look up or install an LSA in the database, you first examine the 
LS type and the LSA's context (i.e., the area or link to which the 
LSA belongs). This information allows you to find the correct 
database of LSAs where you then search based on the LSA's type, Link 
State ID, and Advertising Router. 
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4.4.3. Originating LSAs 


The process of reoriginating an LSA in IPv6 is the same as in IPv4: 
the LSA’s LS sequence number is incremented, its LS age is set to 0, 
its LS checksum is calculated, and the LSA is added to the link state 
database and flooded on the appropriate interfaces. 


The list of events causing LSAs to be reoriginated for IPv4 is given 
in Section 12.4 of [OSPFV2]. The following events and/or actions are 
added for IPv6: 


o The state or interface ID of one of the router's interfaces 
changes. The router may need to (re)originate or flush its link- 
LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If 
the router is the Designated Router, the router may also need to 
(re)originate and/or flush the network-LSA corresponding to the 
interface. 


o The identity of a link's Designated Router changes. The router 
may need to (re)originate or flush the link's network-LSA and one 
or more router-LSAs and/or intra-area-prefix-LSAs. 


o A neighbor transitions to/from "Full" state. The router may need 
to (re)originate or flush the link's network-LSA and one or more 
router-LSAs and/or intra-area-prefix-LSAs. 


o The Interface ID of a neighbor changes. This may cause a new 
instance of a router-LSA to be originated for the associated area. 


o A new prefix is added to an attached link, or a prefix is deleted 
(both through configuration). This causes the router to 
reoriginate its link-LSA for the link or, if it is the only router 
attached to the link, causes the router to reoriginate an intra- 
area-prefix-LSA. 


o A new link-LSA is received, causing the link's collection of 
prefixes to change. If the router is the Designated Router for 
the link, it originates a new intra-area-prefix-LSA. 


o A new link-LSA is received, causing the logical OR of LSA options 
advertised by adjacent routers on the link to change. If the 
router is the Designated Router for the link, it originates a new 
network-LSA. 


Detailed construction of the seven required IPv6 LSA types is 


supplied by the following subsections. In order to display example 
LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to 
show IPv6 addressing, resulting in Figure 1. The OSPF cost of each 
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interface is displayed in Figure 1. The assignment of IPv6 prefixes 
to network links is shown in Table 1. A single area address range 
has been configured for Area 1, so that outside of Area 1 all of its 
prefixes are covered by a single route to 2001:0db8:c001::/48. The 
OSPF interface IDs and the link-local addresses for the router 
interfaces in Figure 1 are given in Table Z2. 


Area 1 
+ 
| 
| 3+---+1 
N1 |--|RT1|----- + 
| +---+ \ 
| \ 
+ \/ \ 1+---+ 
* N3 | *------ [RT4|------ 
t /\ 十 一 一 一 十 
| / | 
| 34---41 / | 
N2 |--|RT2|----- + 1| 
十 一 一 一 十 十 一 一 一 十 
| RT3 | ---------------- 
+ 十 一 一 一 十 
| 2 
| 
4R------------ + 
N4 


N1 2001:0db8:c001:0200::/56 
N2 2001:0db8:c001:0300::/56 
N3 2001:0db8:c001:0100::/56 
N4 2001:0db8:c001:0400::/56 


Table 1: IPv6 Link Prefixes for Sample Network 
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Router Interface Interface ID link-local address 
RT1 to N1 1 fe80:0001::RT1 

to N3 2 fe80:0002::RT1 
RT2 to N2 T. fe80:0001::RT2 

to N3 2 fe80:0002::RT2 
RT3 to N3 1 fe80:0001::RT3 

to N4 2 fe80:0002::RT3 

1 


RT4 to N3 
Table 2: OSPF Interface IDs and Link-Local Addresses 
Figure 1 
4.4.3.1. LSA Options 


The Options field in LSAs should be coded as follows. The V6-bit 
should be set unless the router will not participate in transit IPv6 
routing. The E-bit should be clear if and only if the attached area 
is an OSPF stub or OSPF NSSA area. The E-bit should always be set in 
AS scoped LSAs. The N-bit should be set if and only if the attached 
area is an OSPF NSSA area. The R-bit should be set unless the router 
will not participate in any transit routing. The DC-bit should be 
set if and only if the router can correctly process the DoNotAge bit 
when it appears in the LS age field of LSAs (see [DEMAND]). All 
unrecognized bits in the Options field should be cleared. 


The V6-bit and R-bit are only examined in Router-LSAs during the SPF 
computation. In other LSA types containing options, they are set for 
informational purposes only. 


4.4.3.2.  Router-LSAs 


The LS type of a router-LSA is set to the value 0x2001.  Router-LSAs 
have area flooding scope. A router MAY originate one or more router- 
LSAs for a given area. Each router-LSA contains an integral number 
of interface descriptions. Taken together, the collection of router- 
LSAs originated by the router for an area describes the collected 
states of all the router's interfaces attached to the area. When 
multiple router-LSAs are used, they are distinguished by their Link 
State ID fields. 


To the left of the Options field, the router capability bits V, E, 
and B should be set according to Section 12.4.1 of [OSPFV2]. 


Each of the router's interfaces to the area is then described by 


appending "link descriptions" to the router-LSA. Each link 
description is 16 bytes long, consisting of five fields: (link) Type, 
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Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID 
(see Appendix A.4.3). Interfaces in the state "Down" or "Loopback" 
are not described (although looped back interfaces can contribute 
prefixes to intra-area-prefix-LSAs), nor are interfaces without any 
full adjacencies described (except in the case of multiple Standby 
Interfaces as described in Section 4.9). All other interfaces to the 
area add zero, one, or more link descriptions. The number and 
content of these depend on the interface type. Within each link 
description, the Metric field is always set to the interface’s output 
cost, and the Interface ID field is set to the interface’s OSPF 
Interface ID. 


Point-to-point interfaces 
If the neighboring router is fully adjacent, add a Type 1 link 
description (point-to-point). The Neighbor Interface ID field is 
set to the Interface ID advertised by the neighbor in its Hello 
packets, and the Neighbor Router ID field is set to the neighbor’s 
Router ID. 


Broadcast and NBMA interfaces 
If the router is fully adjacent to the link’s Designated Router or 
if the router itself is the Designated Router and is fully 
adjacent to at least one other router, add a single Type 2 link 
description (transit network). The Neighbor Interface ID field is 
set to the Interface ID advertised by the Designated Router in its 
Hello packets, and the Neighbor Router ID field is set to the 
Designated Router’s Router ID. 


Virtual links 
If the neighboring router is fully adjacent, add a Type 4 link 
description (virtual). The Neighbor Interface ID field is set to 
the Interface ID advertised by the neighbor in its Hello packets, 
and the Neighbor Router ID field is set to the neighbor’s Router 
ID. Note that the output cost of a virtual link is calculated 
during the routing table calculation (see Section 4.7). 


Point-to-Multipoint interfaces 
For each fully adjacent neighbor associated with the interface, 
add a separate Type 1 link description (point-to-point) with the 
Neighbor Interface ID field set to the Interface ID advertised by 
the neighbor in its Hello packets and the Neighbor Router ID field 
set to the neighbor’s Router ID. 


As an example, consider the router-LSA that router RT3 would 
originate for Area 1 in Figure 1. Only a single interface must be 
described, namely, that which connects to the transit network N3. It 
assumes that RT4 has been elected the Designated Router of Network 
N3. 
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; RT3’s router-LSA for Area 1 


LS age = 0 ;newly (re) originated 
LS type = 0x2001 ;router-LSA 
Link State ID = 0 ;first fragment 
Advertising Router = 192.0.2.3 ;RT3’s Router ID 
bit E = 0 ;not an AS boundary router 
bit B = 1 ;area border router 
Options = (V6-bit|E-bit|R-bit) 
Type = 2 ;connects to N3 
Metric = 1 ;cost to N3 
Interface ID = 1 ;RT3’s Interface ID on N3 
Neighbor Interface ID = 1 ;RT4’s Interface ID on N3 


Neighbor Router ID = 192.0.2.4 ; RT4’s Router ID 
RT3’s router-LSA for Area 1 


For example, if another router was added to Network N4, RT3 would 
have to advertise a second link description for its connection to 


(the now transit) network N4. This could be accomplished by 
reoriginating the above router-LSA, this time with two link 
descriptions. Or, a separate router-LSA could be originated with a 


Separate Link State ID (e.g., using a Link State ID of 1) to describe 
the connection to N4. 


Host routes for stub networks no longer appear in the router-LSA. 
Rather, they are included in intra-area-prefix-LSAs. 


4.4.3.3.  Network-LSAs 


The LS type of a network-LSA is set to the value 0x2002.  Network- 
LSAs have area flooding scope. A network-LSA is originated for every 
broadcast or NBMA link with an elected Designated Router that is 
fully adjacent with at least one other router on the link. The 
network-LSA is originated by the link's Designated Router and lists 
all routers on the link with which it is fully adjacent. 


The procedure for originating network-LSAs in IPv6 is the same as the 
IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the 
following exceptions: 


o An IPv6 network-LSA's Link State ID is set to the Interface ID of 
the Designated Router on the link. 


o IPv6 network-LSAs do not contain a Network Mask. All addressing 
information formerly contained in the IPv4 network-LSA has now 
been consigned to intra-Area-Prefix-LSAs originated by the link's 
Designated Router. 
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o The Options field in the network-LSA is set to the logical OR of 
the Options fields contained within the link’s associated link- 
LSAs corresponding to fully adjacent neighbors. In this way, the 
network link exhibits a capability when at least one fully 
adjacent neighbor on the link requests that the capability be 
advertised. 


As an example, assuming that Router RT4 has been elected the 
Designated Router of Network N3 in Figure 1, the following network- 


LSA is originated: 


; Network-LSA for Network N3 


LS age = 0 ;newly (re)originated 

LS type = 0x2002 ;network-LSA 

Link State ID = 1 ;RT4’s Interface ID on N3 

Advertising Router = 192.0.2.4 ;RT4’s Router ID 

Options = (V6-bit|E-bit|R-bit) 
Attached Router = 192.0.2.4 ;Router ID 
Attached Router = 192.0.2.1 ;Router ID 
Attached Router = 192.0.2.2 ;Router ID 
Attached Router = 192.0.2.3 ;Router ID 


Network-LSA for Network N3 
4.4.3.4.  Inter-Area-Prefix-LSAs 


The LS type of an inter-area-prefix-LSA is set to the value 0x2003. 
Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter- 
area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area- 
prefix-LSA describes a prefix external to the area, yet internal to 
the Autonomous System. 


The procedure for originating inter-area-prefix-LSAs in IPv6 is the 
same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1 
of [OSPFV2], with the following exceptions: 


o The Link State ID of an inter-area-prefix-LSA has lost all of its 
addressing semantics and simply serves to distinguish multiple 
inter-area-prefix-LSAs that are originated by the same router. 

o The prefix is described by the PrefixLength, PrefixOptions, and 
Address Prefix fields embedded within the LSA body. Network Mask 


is no longer specified. 


o The NU-bit in the PrefixOptions field should be clear. 
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o Link-local addresses MUST never be advertised in inter-area- 
prefix-LSAs. 


As an example, the following shows the inter-area-prefix-LSA that 
Router RT4 originates into the OSPF backbone area, condensing all of 
Area 1’s prefixes into the single prefix 2001:0db8:c001::/48. The 
cost is set to 4, which is the maximum cost of all of the individual 


component prefixes. The prefix is padded out to an even number of 
32-bit words, so that it consumes 64 bits of space instead of 48 
bits. 


; Inter-area-prefix-LSA for Area 1 addresses 
; originated by Router RT4 into the backbone 


LS age = 0 ;newly (re)originated 
LS type = 0x2003 ;inter-area-prefix-LSA 
Advertising Router = 192.0.2.4 ;RT4’s ID 
Metric = 4 ;maximum to components 
PrefixLength - 48 

PrefixOptions - 0 


Address Prefix - 2001:0db8:c001 ;padded to 64-bits 


Inter-area-prefix-LSA for Area 1 addresses originated 


by Router 
RT4 into the backbone 


4.4.3.5.  Inter-Area-Router-LSAs 


The LS type of an inter-area-router-LSA is set to the value 0x2004. 
Inter-area-router-LSAs have area flooding scope. In IPv4, inter- 
area-router-LSAs were called type 4 summary-LSAs. Each inter-area- 
router-LSA describes a path to a destination OSPF router (i.e., an AS 
Boundary Router (ASBR)) that is external to the area yet internal to 
the Autonomous System. 


The procedure for originating inter-area-router-LSAs in IPv6 is the 
same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2], 
with the following exceptions: 


o The Link State ID of an inter-area-router-LSA is no longer the 
destination router's OSPF Router ID and now simply serves to 
distinguish multiple inter-area-router-LSAs that are originated by 
the same router. The destination router's Router ID is now found 
in the body of the LSA. 
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o The Options field in an inter-area-router-LSA should be set equal 
to the Options field contained in the destination router’s own 
router-LSA. The Options field thus describes the capabilities 
supported by the destination router. 


As an example, consider the OSPF Autonomous System depicted in Figure 
6 of [OSPFV2]. Router RT4 would originate into Area 1 the following 
inter-area-router-LSA for destination router RT7. 


; inter-area-router-LSA for AS boundary router RT7 
; originated by Router RT4 into Area 1 


LS age = 0 ;newly (re) originated 
LS type = 0x2004 ;inter-area-router-LSA 
Advertising Router = 192.0.2.4 ;RT4’s ID 

Options = (V6-bit|E-bit|R-bit)  ;RT7's capabilities 
Metric = 14 ;cost to RT7 


Destination Router ID = Router RT7's ID 


Inter-area-router-LSA for AS boundary router RT7 originated by Router 
RT4 into Area 1 


4.4.3.6. AS-External-LSAs 


The LS type of an AS-external-LSA is set to the value 0x4005. AS- 
external-LSAs have AS flooding scope. Each AS-external-LSA describes 
a path to a prefix external to the Autonomous System. 


The procedure for originating AS-external-LSAs in IPv6 is the same as 
the IPv4 procedure documented in Section 12.4.4 of [OSPFV2], with the 
following exceptions: 


o The Link State ID of an AS-external-LSA has lost all of its 
addressing semantics and simply serves to distinguish multiple AS- 
external-LSAs that are originated by the same router. 

o The prefix is described by the PrefixLength, PrefixOptions, and 
Address Prefix fields embedded within the LSA body. Network Mask 
is no longer specified. 

o The NU-bit in the PrefixOptions field should be clear. 


o Link-local addresses can never be advertised in AS-external-LSAs. 


o The forwarding address is present in the AS-external-LSA if and 
only if the AS-external-LSA's bit F is set. 
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oO The external route tag is present in the AS-external-LSA if and 
only if the AS-external-LSA's bit T is set. 


o The capability for an AS-external-LSA to reference another LSA has 
been supported through the inclusion of the Referenced LS Type 
field and the optional Referenced Link State ID field (the latter 
present if and only if the Referenced LS Type is non-zero). This 
capability is for future use; the Referenced LS Type should be set 
to 0, and received non-zero values for this field should be 
ignored until its use is defined. 


As an example, consider the OSPF Autonomous System depicted in Figure 
6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP 
and that it wishes to advertise a Type 2 metric into the AS. Also 
assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40. 
RT7 would then originate the following AS-external-LSA for the 
external network N12. Note that within the AS-external-LSA, N12's 
prefix occupies 64 bits of space in order to maintain 32-bit 
alignment. 


; AS-external-LSA for Network N12, 
; originated by Router RT7 


LS age = 0 ;newly (re)originated 

LS type = 0x4005 ;AS-external-LSA 

Link State ID = 123 PLSA type/scope unique identifier 
Advertising Router - Router RT7's ID 

bit E = 1 ;Type 2 metric 

bit F = 0 ;no forwarding address 

bit T= 1 ;external route tag included 


Metric = 2 

PrefixLength - 40 

PrefixOptions - 0 

Referenced LS Type - 0 ;no Referenced Link State ID 
Address Prefix - 2001:0db8:0a00 ;padded to 64-bits 
External Route Tag = as per BGP/OSPF interaction 


AS-external-LSA for Network N12, originated by Router RT7 
4.4.3.7. NSSA-LSAs 
The LS type of an NSSA-LSA is set to the value 0x2007.  NSSA-LSAs 
have area flooding scope. Each NSSA-LSA describes a path to a prefix 
external to the Autonomous System whose flooding scope is restricted 


to a single NSSA area. 


The procedure for originating NSSA-LSAs in IPv6 is the same as the 
IPv4 procedure documented in [NSSA], with the following exceptions: 
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o The Link State ID of an NSSA-LSA has lost all of its addressing 
semantics and simply serves to distinguish multiple NSSA-LSAs that 
are originated by the same router in the same area. 


o The prefix is described by the PrefixLength, PrefixOptions, and 
Address Prefix fields embedded within the LSA body. Network Mask 


is no longer specified. 


o The NU-bit in the PrefixOptions field should be clear. 


o Link-local addresses can never be advertised in NSSA-LSAs. 


o The forwarding address is present in the NSSA-LSA if and only if 
the NSSA-LSA's bit F is set. 


o The external route tag is present in the NSSA-LSA if and only if 
the NSSA-LSA's bit T is set. 


o The capability for an NSSA-LSA to reference another LSA has been 
supported through the inclusion of the Referenced LS Type field 
and the optional Referenced Link State ID field (the latter 
present if and only if the Referenced LS Type is non-zero). This 
capability is for future use; the Referenced LS Type should be set 
to 0, and received non-zero values for this field should be 
ignored until its use is defined. 


An example of an NSSA-LSA would only differ from an AS-external-LSA 
in that the LS type would be 0x2007 rather than 0x4005. 


4.4.3.8.  Link-LSAs 


The LS type of a link-LSA is set to the value 0x0008.  Link-LSAs have 
link-local flooding scope. A router originates a separate link-LSA 
for each attached link that supports two or more (including the 
originating router itself) routers.  Link-LSAs SHOULD NOT be 
originated for virtual links. 


Link-LSAs have three purposes: 


1. They provide the router's link-local address to all other routers 
attached to the link. 


2. They inform other routers attached to the link of a list of IPv6 
prefixes to associate with the link. 


3. They allow the router to advertise a collection of Options bits 


in the network-LSA originated by the Designated Router on a 
broadcast or NBMA link. 
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A link-LSA for a given Link L is built in the following fashion: 
o The Link State ID is set to the router’s Interface ID on Link L. 


o The Router Priority of the router’s interface to Link L is 
inserted into the link-LSA. 


o The link-LSA's Options field is set to reflect the router's 
capabilities. On multi-access links, the Designated Router will 
logically OR the link-LSA Options fields for all fully adjacent 
neighbors in Link L's network-LSA. 


o The router inserts its link-local address on Link L into the link- 
LSA. This information will be used when the other routers on Link 
L do their next-hop calculations (see Section 4.8.2). 


o Each IPv6 address prefix that has been configured on Link L is 
added to the link-LSA by specifying values for the PrefixLength, 
PrefixOptions, and Address Prefix fields. 


After building a link-LSA for a given link, the router installs the 
link-LSA into the associated interface data structure and floods the 
link-LSA on the link. All other routers on the link will receive the 
link-LSA, but they will not flood the link-LSA on other links. 


If LinkLSASuppression is configured for the interface and the 

interface type is not broadcast or NBMA, origination of the link-LSA 
may be suppressed. This implies that other routers on the link will 
ascertain the router's next-hop address using a mechanism other than 


the link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a 
description of the LinkLSASuppression interface configuration 
parameter. 


As an example, consider the link-LSA that RT3 will build for N3 in 
Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been 
configured within RT3 for N3. This will result in the following 
link-LSA that RT3 will flood only on N3. Note that not all routers 
on N3 need be configured with the prefix; those not configured will 
learn the prefix when receiving RT3's link-LSA. 
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; RT3’s link-LSA for N3 


LS age = 0 ;newly (re) originated 

LS type = 0x0008 ; link-LSA 

Link State ID = 1 ;RT3’s Interface ID on N3 
Advertising Router = 192.0.2.3 ;RT3’s Router ID 

Rtr Priority = 1 ;RT3’s N3 Router Priority 
Options = (V6-bit|E-bit|R-bit) 

Link-local Interface Address = fe80:0001::RT3 

# prefixes = 1 

PrefixLength = 56 

PrefixOptions = 0 


Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits 


RT3’s link-LSA for N3 


4.4.3.9.  Intra-Area-Prefix-LSAs 


The LS type of an intra-area-prefix-LSA is set to the value 0x2009. 
Intra-area-prefix-LSAs have area flooding scope. An intra-area- 
prefix-LSA has one of two functions. It either associates a list of 
IPv6 address prefixes with a transit network link by referencing a 
network-LSA, or associates a list of IPv6 address prefixes with a 
router by referencing a router-LSA. A stub link's prefixes are 
associated with its attached router. 


A router MAY originate multiple intra-area-prefix-LSAs for a given 
area. Each intra-area-prefix-LSA has a unique Link State ID and 
contains an integral number of prefix descriptions. 


A link's Designated Router originates one or more intra-area-prefix- 
LSAs to advertise the link's prefixes throughout the area. For a 
link L, L's Designated Router builds an intra-area-prefix-LSA in the 
following fashion: 


o In order to indicate that the prefixes are to be associated with 
the Link L, the fields Referenced LS Type, Referenced Link State 
ID, and Referenced Advertising Router are set to the corresponding 
fields in Link L's network-LSA (namely, LS type, Link State ID, 
and Advertising Router respectively). This means that the 
Referenced LS Type is set to 0x2002, the Referenced Link State ID 
is set to the Designated Router's Interface ID on Link L, and the 
Referenced Advertising Router is set to the Designated Router's 
Router ID. 


o Each link-LSA associated with Link L is examined (these are in the 
Designated Router's interface structure for Link L). If the link- 
LSA's Advertising Router is fully adjacent to the Designated 
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Router and the Link State ID matches the neighbor’s interface ID, 
the list of prefixes in the link-LSA is copied into the intra- 
area-prefix-LSA that is being built. Prefixes having the NU-bit 
and/or LA-bit set in their Options field SHOULD NOT be copied, nor 
should link-local addresses be copied. Each prefix is described 
by the PrefixLength, PrefixOptions, and Address Prefix fields. 
Multiple prefixes having the same PrefixLength and Address Prefix 
are considered to be duplicates. In this case, their 
PrefixOptions fields should be logically OR'ed together, and a 
single instance of the duplicate prefix should be included in the 
intra-area-prefix-LSA. The Metric field for all prefixes is set 
to 0. 


The "£ prefixes" field is set to the number of prefixes that the 
router has copied into the LSA. If necessary, the list of 
prefixes can be spread across multiple intra-area-prefix-LSAs in 
order to keep the LSA size small. 


A router builds an intra-area-prefix-LSA to advertise prefixes for 
its attached stub links, looped-back interfaces, and hosts. A Router 
RTX would build its intra-area-prefix-LSA in the following fashion: 


o 


In order to indicate that the prefixes are to be associated with 

the Router RTX itself, RTX sets the Referenced LS Type to 0x2001, 
the Referenced Link State ID to 0, and the Referenced Advertising 
Router to RTX’s own Router ID. 


Router RTX examines its list of interfaces to the area. If the 
interface is in the state Down, its prefixes are not included. If 
the interface has been reported in RTX's router-LSA as a Type 2 
link description (link to transit network), prefixes that will be 
included in the intra-area-prefix-LSA for the link are skipped. 
However, any prefixes that would normally have the LA-bit set 
SHOULD be advertised independent of whether or not the interface 
is advertised as a transit link. If the interface type is point- 
to-multipoint or the interface is in the state Loopback, the 
global scope IPv6 addresses associated with the interface (if any) 
are copied into the intra-area-prefix-LSA with the PrefixOptions 
LA-bit set, the PrefixLength set to 128, and the metric set to 0. 
Otherwise, the list of global prefixes configured in RTX for the 
link are copied into the intra-area-prefix-LSA by specifying the 
PrefixLength, PrefixOptions, and Address Prefix fields. The 
Metric field for each of these prefixes is set to the interface's 
output cost. 


RTX adds the IPv6 prefixes for any directly attached hosts 
belonging to the area (see Appendix C.7) to the intra-area-prefix- 
LSA. 
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o If RTX has one or more virtual links configured through the area, 
it includes one of its global scope IPv6 interface addresses in 
the LSA (if it hasn't already), setting the LA-bit in the 
PrefixOptions field, the PrefixLength to 128, and the Metric to O0. 
This information will be used later in the routing calculation so 
that the two ends of the virtual link can discover each other's 
IPv6 addresses. 


o The "f prefixes" field is set to the number of prefixes that the 
router has copied into the LSA. If necessary, the list of 
prefixes can be spread across multiple intra-area-prefix-LSAs in 
order to keep the LSA size small. 


For example, the intra-area-prefix-LSA originated by RT4 for Network 
N3 (assuming that RT4 is N3's Designated Router) and the intra-area- 
prefix-LSA originated into Area 1 by Router RT3 for its own prefixes 
are pictured below. 
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; RT4’s Intra-area-prefix-LSA for network link N3 


LS age = 0 ;newly (re) originated 
LS type = 0x2009 ;Intra-area-prefix-LSA 
Link State ID = 5 ;LSA type/scope unique identifier 


Advertising Router 192.0.2.4 ;RT4’s Router ID 

# prefixes = 1 

Referenced LS Type = 0x2002 ;network-LSA reference 
Referenced Link State ID = 1 

Referenced Advertising Router = 192.0.2.4 
PrefixLength = 56 ;N3’s prefix 
PrefixOptions = 0 

Metric = 0 

Address Prefix = 2001:0db8:c001:0100 ;pad 


; RT3’s Intra-area-prefix-LSA for its own prefixes 


LS age = 0 ;newly (re) originated 

LS type = 0x2009 ;Intra-area-prefix-LSA 

Link State ID - 177 ;LSA type/scope unique identifier 
Advertising Router = 192.0.2.3 ;RT3’s Router ID 

# prefixes = 1 


Referenced LS Type = 0x2001 ;router-LSA reference 
Referenced Link State ID = 0 
Referenced Advertising Router = 192.0.2.3 


PrefixLength = 56 ;N4’s prefix 
PrefixOptions = 0 
Metric = 2 ;N4 interface cost 


Address Prefix = 2001:0db8:c001:0400 ;pad 
Intra-area-prefix-LSA for Network Link N3 


When network conditions change, it may be necessary for a router to 
move prefixes from one intra-area-prefix-LSA to another. For 
example, if the router is the Designated Router for a link but the 
link has no other attached routers, the link's prefixes are 
advertised in an intra-area-prefix-LSA referring to the Designated 
Router's router-LSA. When additional routers appear on the link, a 
network-LSA is originated for the link and the link's prefixes are 
moved to an intra-area-prefix-LSA referring to the network-LSA. 


Note that in the intra-area-prefix-LSA, the Referenced Advertising 
Router is always equal to the router that is originating the intra- 
area-prefix-LSA (i.e., the LSA's Advertising Router). The reason the 
Referenced Advertising Router field appears is that, even though it 
is currently redundant, it may not be in the future. We may sometime 
want to use the same LSA format to advertise address prefixes for 
other protocol suites. In this case, the Designated Router may not 
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be running the other protocol suite, and so another of the link’s 
routers may need to originate the intra-area-prefix-LSA. In that 
case, the Referenced Advertising Router and Advertising Router would 
be different. 


4.4.4. Future LSA Validation 


It is expected that new LSAs will be defined that will not be 
processed during the Shortest Path First (SPF) calculation as 
described in Section 4.8, for example, OSPFv3 LSAs corresponding to 
information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In 
general, the new information advertised in future LSAs should not be 
used unless the OSPFv3 router originating the LSA is reachable. 
However, depending on the application and the data advertised, this 
reachability validation MAY be done less frequently than every SPF 
calculation. 


To facilitate inter-area reachability validation, any OSPFv3 router 
originating AS scoped LSAs is considered an AS Boundary Router 
(ASBR). 


4.5. Flooding 


Most of the flooding algorithm remains unchanged from the IPv4 
flooding mechanisms described in Section 13 of [OSPFV2]. In 
particular, the protocol processes for determining which LSA instance 
is newer (Section 13.1 of [OSPFV2]), responding to updates of self- 
originated LSAs (Section 13.4 of [OSPFV2]), sending Link State 
Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting 
LSAs (Section 13.6 of [OSPFV2]), and receiving Link State 
Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the 
same for IPv6 and IPv4. 


However, the addition of flooding scope and unknown LSA type handling 
(see Appendix A.4.2.1) has caused some changes in the OSPF flooding 
algorithm: the reception of Link State Updates (Section 13 in 
[OSPFV2]) and the sending of Link State Updates (Section 13.3 of 
[OSPFV2]) must take into account the LSA's scope and U-bit setting. 
Also, installation of LSAs into the OSPF database (Section 13.2 of 
[OSPFV2]) causes different events in IPv6, due to the reorganization 
of LSA types and the IPv6 LSA contents. These changes are described 
in detail below. 


4.5.1. Receiving Link State Update Packets 
The encoding of flooding scope in the LS type and the need to process 


unknown LS types cause modifications to the processing of received 
Link State Update packets. As in IPv4, each LSA in a received Link 
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State Update packet is examined. In IPv4, eight steps are executed 
for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all 
the steps are the same, except that Steps 2 and 3 are modified as 
follows: 


(2) Examine the LSA’s LS type. Discard the LSA and get 
the next one from the Link State Update packet if the 
interface area has been configured as a stub or 
NSSA area and the LS type indicates "AS flooding scope". 


This generalizes the IPv4 behavior where AS-external-LSAs 
and AS-scoped opaque LSAs [OPAQUE] are not flooded 
throughout stub or NSSA areas. 


(3) Else if the flooding scope in the LSA’s LS type is set to 
"reserved", discard the LSA and get the next one from 
the Link State Update packet. 


Steps 5b (sending Link State Update packets) and 5d (installing LSAs 
in the link-state database) in Section 13 of [OSPFV2] are also 
somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3 
below. 


4.5.2. Sending Link State Update Packets 


The sending of Link State Update packets is described in Section 13.3 


of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State 
Update packet are the same (steps 1 through 5 of Section 13.3 in 
[OSPFV2]). However, the list of eligible interfaces on which to 


flood the LSA is different. For IPv6, the eligible interfaces are 
selected based on the following factors: 


o The LSA’s flooding scope. 


o For LSAs with area or link-local flooding scope, the particular 
area or interface with which the LSA is associated. 


o Whether the LSA has a recognized LS type. 
o The setting of the U-bit in the LS type. If the U-bit is set to 
0, unrecognized LS types are treated as having link-local scope. 


If set to 1, unrecognized LS types are stored and flooded as if 
they were recognized. 
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Choosing the set of eligible interfaces then breaks into the 
following cases: 


Case 1 
The LSA's LS type is recognized. In this case, the set of 
eligible interfaces is set depending on the flooding scope encoded 
in the LS type. If the flooding scope is "AS flooding scope", the 
eligible interfaces are all router interfaces excepting virtual 
links. In addition, AS-external-LSAs are not flooded on 
interfaces connecting to stub or NSSA areas. If the flooding 
Scope is "area flooding scope", the eligible interfaces are those 
interfaces connecting to the LSA's associated area. If the 
flooding scope is "link-local flooding scope", then there is a 
single eligible interface, the one connecting to the LSA's 
associated link (which is also the interface on which the LSA was 
received in a Link State Update packet). 


Case 2 
The LS type is unrecognized and the U-bit in the LS type is set to 
0 (treat the LSA as if it had link-local flooding scope). In this 


case, there is a single eligible interface, namely, the interface 
on which the LSA was received. 


Case 3 
The LS type is unrecognized, and the U-bit in the LS type is set 
to 1 (store and flood the LSA as if the type is understood). In 


this case, select the eligible interfaces based on the encoded 
flooding scope the same as in Case 1 above. 


A further decision must sometimes be made before adding an LSA to a 
given neighbor's link-state retransmission list (Step ld in Section 
13.3 of [OSPFV2]). If the LS type is recognized by the router but 
not by the neighbor (as can be determined by examining the Options 
field that the neighbor advertised in its Database Description 
packet) and the LSA's U-bit is set to 0, then the LSA should be added 
to the neighbor's link-state retransmission list if and only if that 
neighbor is the Designated Router or Backup Designated Router for the 
attached link. The LS types described in detail by this document, 
namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter- 
area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs 
(0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- 
Area-Prefix-LSAs (0x2009), are assumed to be understood by all 
routers. However, all LS types MAY not be understood by all routers. 
For example, a new LSA type with its U-bit set to 0 MAY only be 
understood by a subset of routers. This new LS type should only be 
flooded to an OSPF neighbor that understands the LS type or when the 
neighbor is the Designated Router or Backup Designated Router for the 
attached link. 
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The previous paragraph solves a problem for IPv4 OSPF extensions, 
which require that the Designated Router support the extension in 
order to have the new LSA types flooded across broadcast and NBMA 
networks. 


4.5.3. Installing LSAs in the Database 


There are three separate places to store LSAs, depending on their 
flooding scope. LSAs with AS flooding scope are stored in the global 
OSPF data structure (see Section 4.1) as long as their LS type is 
known or their U-bit is 1. LSAs with area flooding scope are stored 
in the appropriate area data structure (see Section 4.1.1) as long as 
their LS type is known or their U-bit is 1. LSAs with link-local 
flooding scope, and those LSAs with unknown LS type and U-bit set to 
0 (treat the LSA as if it had link-local flooding scope), are stored 
in the appropriate interface data structure. 


When storing the LSA into the link-state database, a check must be 
made to see whether the LSA's contents have changed. Changes in 
contents are indicated exactly as in Section 13.2 of [OSPFV2]. When 
an LSA's contents have been changed, the following parts of the 
routing table must be recalculated, based on the LSA's LS type: 


Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs 
The entire routing table is recalculated, starting with the 
shortest-path calculation for each area (see Section 4.8). 


Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs 
The best route to the destination described by the LSA must be 
recalculated (see Section 16.5 in [OSPFV2]). If this destination 
is an AS boundary router, it may also be necessary to re-examine 
all the AS-external-LSAs. 


AS-external-LSAs and NSSA-LSAs 
The best route to the destination described by the AS-external-LSA 
or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and 
Section 2.0 in [NSSA]). 


As in IPv4, any old instance of the LSA must be removed from the 
database when the new LSA is installed. This old instance must also 
be removed from all neighbors' link-state retransmission lists. 


4.6. Definition of Self-Originated LSAs 
In IPv6, the definition of a self-originated LSA has been simplified 
from the IPv4 definition appearing in Sections 13.4 and 14.1 of 


[OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose 
Advertising Router is equal to the router's own Router ID. 
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4.7. 


Virtual Links 


OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. 
Virtual links are the same in IPv6, with the following exceptions: 


o 


LSAs having AS flooding scope are never flooded over virtual 
adjacencies, nor are LSAs with AS flooding scope summarized over 
virtual adjacencies during the database exchange process. This is 
a generalization of the IPv4 treatment of AS-external-LSAs. 


The IPv6 interface address of a virtual link MUST be an IPv6 
address having global scope, instead of the link-local addresses 
used by other interface types. This address is used as the IPv6 
Source for OSPF protocol packets sent over the virtual link. 
Hence, a link-LSA SHOULD NOT be originated for a virtual link 
Since the virtual link has no link-local address or associated 
prefixes. 


Likewise, the virtual neighbor's IPv6 address is an IPv6 address 
with global scope. To enable the discovery of a virtual 
neighbor's IPv6 address during the routing calculation, the 
neighbor advertises its virtual link's IPv6 interface address in 
an intra-area-prefix-LSA originated for the virtual link's transit 
area (see Section 4.4.3.9 and Section 4.8.1). 


Like all other IPv6 OSPF interfaces, virtual links are assigned 
unique (within the router) Interface IDs. These are advertised in 


Hellos sent over the virtual link and in the router's router-LSAs. 


Routing Table Calculation 


The IPv6 OSPF routing calculation proceeds along the same lines as 
the IPv4 OSPF routing calculation, following the five steps specified 
by Section 16 of [OSPFV2]. High-level differences between the IPv6 
and IPv4 calculations include: 


o 


Prefix information has been removed from router-LSAs and network- 
LSAs and is now advertised in intra-area-prefix-LSAs. Whenever 
[OSPFV2] specifies that stub networks within router-LSAs be 
examined, IPv6 will instead examine prefixes within intra-area- 
prefix-LSAs. 


Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs 
and inter-area-router-LSAs respectively. 
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o Addressing information is no longer encoded in Link State IDs and 
is now only found within the body of LSAs. 


o In IPv6, a router can originate multiple router-LSAs, 
distinguished by Link State ID, within a single area. These 
router-LSAs MUST be treated as a single aggregate by the area's 
shortest-path calculation (see Section 4.8.1). 


For each area, the shortest-path tree calculation creates routing 
table entries for the area's routers and transit links (see 

Section 4.8.1). These entries are then used when processing intra- 
area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, 
as described in Section 4.8.3. 


Events generated as a result of routing table changes (Section 16.7 
of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of 
[OSPFV2]) are identical for both IPv4 and IPv6. 


4.8.1. Calculating the Shortest-Path Tree for an Area 


The IPv4 shortest-path calculation is contained in Section 16.1 of 
[OSPFV2]. The graph used by the shortest-path tree calculation is 
identical for both IPv4 and IPv6. The graph's vertices are routers 
and transit links, represented by router-LSAs and network-LSAs 
respectively. A router is identified by its OSPF Router ID, while a 
transit link is identified by its Designated Router's Interface ID 
and OSPF Router ID. Both routers and transit links have associated 
routing table entries within the area (see Section 4.3). 


Section 16.1 of [OSPFV2] splits up the shortest-path calculations 
into two stages. First, the Dijkstra calculation is performed, and 
then the stub links are added onto the tree as leaves. The IPv6 
calculation maintains this split. 


The Dijkstra calculation for IPv6 is identical to that specified for 
IPv4, with the following exceptions (referencing the steps from the 
Dijkstra calculation as described in Section 16.1 of [OSPFV2]): 


o The Vertex ID for a router is the OSPF Router ID. The Vertex ID 
for a transit network is a combination of the Interface ID and 
OSPF Router ID of the network's Designated Router. 


o In Step 2, when a router Vertex V has just been added to the 
shortest-path tree, there may be multiple LSAs associated with the 
router. All router-LSAs with the Advertising Router set to V's 
OSPF Router ID MUST be processed as an aggregate, treating them as 
fragments of a single large router-LSA. The Options field and the 
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router type bits (bits Nt, V, E, and B) should always be taken 
from the router-LSA with the smallest Link State ID. 


O Step 2a is not needed in IPv6, as there are no longer stub network 
links in router-LSAs. 


o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is 
not set in the LSA options, the transit link W is ignored and V's 
next link is examined. 


o In Step 2b, if W is a router, there may again be multiple LSAs 
associated with the router. All router-LSAs with the Advertising 
Router set to W's OSPF Router ID MUST be processed as an 
aggregate, treating them as fragments of a single large router- 
LSA. 


o In Step 4, there are now per-area routing table entries for each 
of an area's routers rather than just the area border routers. 
These entries subsume all the functionality of IPv4's area border 
router routing table entries, including the maintenance of virtual 
links. When the router added to the area routing table in this 
step is the other end of a virtual link, the virtual neighbor's IP 
address is set as follows: The collection of intra-area-prefix- 
LSAs originated by the virtual neighbor is examined, with the 
virtual neighbor's IP address being set to the first prefix 
encountered with the LA-bit set. 


o Routing table entries for transit networks, which are no longer 
associated with IP networks, are also calculated in Step 4 and 
added to the per-area routing table. 


The next stage of the shortest-path calculation proceeds similarly to 
the two steps of the second stage of Section 16.1 in [OSPFV2]. 
However, instead of examining the stub links within router-LSAs, the 
list of the area's intra-area-prefix-LSAs is examined. A prefix 
advertisement whose NU-bit is set SHOULD NOT be included in the 
routing calculation. The cost of any advertised prefix is the sum of 
the prefix's advertised metric plus the cost to the transit vertex 
(either router or transit network) identified by intra-area-prefix- 
LSA's Referenced LS Type, Referenced Link State ID, and Referenced 
Advertising Router fields. This latter cost is stored in the transit 
vertex's routing table entry for the area. 


This specification does not require that the above algorithm be used 
to calculate the intra-area shortest-path tree. However, if another 
algorithm or optimization is used, an identical shortest-path tree 
must be produced. It is also important that any alternate algorithm 
or optimization maintain the requirement that transit vertices must 
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be bidirectional for inclusion in the tree. Alternate algorithms and 
optimizations are beyond the scope of this specification. 


4.8.2. The Next-Hop Calculation 


In IPv6, the calculation of the next-hop's IPv6 address (which will 
be a link-local address) proceeds along the same lines as the IPv4 
next-hop calculation (see Section 16.1.1 of [OSPFV2]). However, 
there are some differences. When calculating the next-hop IPv6 
address for a router (call it Router X) that shares a link with the 
calculating router, the calculating router assigns the next-hop IPv6 
address to be the link-local interface address contained in Router 
X's link-LSA (see Appendix A.4.9) for the link. This procedure is 
necessary for some link types, for example NBMA, where the two 
routers need not be neighbors and might not be exchanging OSPF Hello 
packets. For other link types, the next-hop address may be 
determined via the IPv6 source address in the neighbor's Hello 
packet. 


Additionally, when calculating routes for the area's intra-area- 
prefix-LSAs, the parent vertex can be either a router-LSA or network- 
LSA. This is in contrast to the second stage of the OSPFv2 intra- 
area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always 
a router-LSA. In the case where the intra-area-prefix-LSA's 
referenced LSA is a directly connected network-LSA, the prefixes are 
also considered to be directly connected. In this case, the next hop 
is solely the outgoing link and no IPv6 next-hop address is selected. 


4.8.3. Calculating the Inter-Area Routes 


Calculation of inter-area routes for IPv6 proceeds along the same 
lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the 
following modifications: 


o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have 
been changed to inter-area-prefix-LSAs and inter-area-router-LSAs 
respectively. 


o The Link State ID of the above LSA types no longer encodes the 
network or router described by the LSA. Instead, an address 
prefix is contained in the body of an inter-area-prefix-LSA and an 
advertised AS boundary router's OSPF Router ID is carried in the 
body of an inter-area-router-LSA. 


o Prefixes having the NU-bit set in their PrefixOptions field should 
be ignored by the inter-area route calculation. 
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When a single inter-area-prefix-LSA or inter-area-router-LSA has 
changed, the incremental calculations outlined in Section 16.5 of 
[OSPFV2] can be performed instead of recalculating the entire routing 
table. 


4.8.4. Examining Transit Areas’ Summary-LSAs 


Examination of transit areas’ summary-LSAs in IPv6 proceeds along the 
same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], 
modified in the same way as the IPv6 inter-area route calculation in 
Section 4.8.3. 


4.8.5. Calculating AS External and NSSA Routes 


The IPv6 AS external route calculation proceeds along the same lines 
as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 
of [NSSA], with the following exceptions: 


o The Link State ID of the AS-external-LSA and NSSA-LSA types no 
longer encodes the network described by the LSA. Instead, an 
address prefix is contained in the body of the LSA. 


o The default route in AS-external-LSAs or NSSA-LSAs is advertised 
by a zero-length prefix. 


o Instead of comparing the AS-external-LSA's or NSSA-LSA's 
Forwarding Address field to 0.0.0.0 to see whether a forwarding 
address has been used, the bit F in the respective LSA is 
examined. A forwarding address is in use if and only if bit F is 
set. 


o Prefixes having the NU-bit set in their PrefixOptions field should 
be ignored by the inter-area route calculation. 


o AS Boundary Router (ASBR) and forwarding address selection will 
proceed the same as if RFC1583Compatibility is disabled. 
Furthermore, RFC1583Compatibility is not an OSPF for IPv6 
configuration parameter. Refer to Appendix C.1. 


When a single AS-external-LSA or NSSA-LSA has changed, the 
incremental calculations outlined in Section 16.6 of [OSPFV2] can be 
performed instead of recalculating the entire routing table. 


4.9. Multiple Interfaces to a Single Link 


In OSPF for IPv6, a router may have multiple interfaces to a single 
link associated with the same OSPF instance and area. All interfaces 
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will be used for the reception and transmission of data traffic while 
only a single interface sends and receives OSPF control traffic. In 
more detail: 


o 


Each of the multiple interfaces is assigned a different Interface 
ID. A router will automatically detect that multiple interfaces 
are attached to the same link when a Hello packet is received with 
one of the router's link-local addresses as the source address and 
an Interface ID other than the Interface ID of the receiving 
interface. 


Each of the multiple interfaces MUST be configured with the same 
Interface Instance ID to be considered on the same link. If an 
interface has multiple Instance IDs, it will be grouped with other 
interfaces based on matching Instance IDs. Each Instance ID will 
be treated uniquely with respect to groupings of multiple 
interfaces on the same link. For example, if interface A is 
configured with Instance IDs 1 and 35, and interface B is 
configured with Instance ID 35, interface B may be the Active 
Interface for Instance ID 35 but interface A will be active for 
Instance ID 1. 


The router will ignore OSPF packets other than Hello packets on 
all but one of the interfaces attached to the link. It will only 
send its OSPF control packets (including Hello packets) on a 
single interface. This interface is designated the Active 
Interface and other interfaces attached to the same link will be 
designated Standby Interfaces. The choice of the Active Interface 
is implementation dependent. For example, the interface with the 
highest Interface ID could be chosen. If the router is elected 
Designated Router, it will be the Active Interface's Interface ID 
that will be used as the network-LSA's Link State ID. 


All of the interfaces to the link (Active and Standby) will appear 
in the router-LSA. In addition, a link-LSA will be generated for 
each of the interfaces. In this way, all interfaces will be 
included in OSPF's routing calculations. 


Any link-local scope LSAs that are originated for a Standby 
Interface will be flooded over the Active Interface. 

If a Standby Interface goes down, then the link-local scope LSAs 
originated for the Standby Interfaces MUST be flushed on the 
Active Interface. 


Prefixes on Standby Interfaces will be processed the same way as 
prefixes on the Active Interface. For example, if the router is 
the DR for the link, the Active Interface's prefixes are included 
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in an intra-area-prefix-LSA which is associated with the Active 
Interface's network-LSA; prefixes from Standby Interfaces on the 
link will also be included in that intra-area-prefix LSA. 
Similarly, if the link is a stub link, then the prefixes for the 
Active and Standby Interfaces will all be included in the same 
intra-area-prefix-LSA that is associated with the router-LSA. 


o If the Active Interface fails, a new Active Interface will have to 
take over. The new Active Interface SHOULD form all new neighbor 
adjacencies with routers on the link. This failure can be 
detected when the router's other interfaces to the Active 
Interface's link cease to hear the router's Hellos or through 
internal mechanisms, e.g., monitoring the Active Interface's 
status. 


o If the network becomes partitioned with different local interfaces 
attaching to different network partitions, multiple interfaces 
will become Active Interfaces and function independently. 


o During the SPF calculation when a network-LSA for a network that 
is directly connected to the root vertex is being examined, all of 
the multiple interfaces to the link of adjacent router-LSAs must 
be used in the next-hop calculation. 

This can be accomplished during the back link check (see Section 
16.1, Step 2 (B), in [OSPFV2]) by examining each link of the 
router-LSA and making a list of the links that point to the 
network-LSA. The Interface IDs for links in this list are then 
used to find the corresponding link-LSAs and the link-local 
addresses used as next hops when installing equal-cost paths in 
the routing table. 


o The interface state machine is modified to add the state Standby. 
See Section 4.9.1 for a description of the Standby state. 


1. Standby Interface State 


In this state, the interface is one of multiple interfaces to a link 
and this interface is designated Standby and is not sending or 
receiving control packets. The interface will continue to receive 
the Hello packets sent by the Active Interface. The interface will 
maintain a timer, the Active Interface Timer, with the same interval 
as the RouterDeadInterval. This timer will be reset whenever an OSPF 
Hello packet is received from the Active Interface to the link. 


Two new events are added to the list of events that cause interface 
state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The 
descriptions of these events are as follows: 
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MultipleInterfacesToLink 
An interfaces on the router has received a Hello packet from 
another interface on the same router. One of the interfaces is 
designated as the Active Interface and the other interface is 
designated as a Standby Interface. The Standby Interface 
transitions to the Standby state. 


ActiveInterfaceDead 
There has been an indication that a Standby Interface is no longer 
on a link with an Active Interface. The firing of the Active 
Interface Timer is one indication of this event, as it indicates 
that the Standby Interface has not received an OSPF Hello packet 
from the Active Interface for the RouterDeadInterval. Other 
indications may come from internal notifications, such as the 
Active Interface being disabled through a configuration change. 
Any indication internal to the router, such that the router knows 
the Active Interface is no longer active on the link, can trigger 
the ActiveInterfaceDead event for a Standby Interface. 


Interface state machine additions include: 
State(s): Waiting, DR Other, Backup, or DR 
Event:  MultipleInterfacesToLink 
New state: Standby 
Action: All interface variables are reset and interface 
timers disabled. Also, all neighbor connections 
associated with the interface are destroyed. This 
is done by generating the event KillNbr on all 
associated neighbors. The Active Interface Timer is 
started and the interface will listen for OSPF Hello 
packets from the link's Active Interface. 
State(s): Standby 
Event:  ActiveInterfaceDead 


New state: Down 


Action: The Active Interface Timer is first disabled. Then 
the InterfaceUp event is invoked. 


Standby Interface State Machine Additions 
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5. Security Considerations 


When running over IPv6, OSPFv3 relies on the IP Authentication Header 
(see [IPAUTH]) and the IP Encapsulating Security Payload (see 
[IPESP]) to ensure integrity and authentication/confidentiality of 
protocol packets. This is described in [OSPFV3-AUTH]. 


Most OSPFv3 implementations will be running on systems that support 
multiple protocols with their own independent security assumptions 
and domains. When IPsec is used to protect OSPFv3 packets, it is 
important for the implementation to check the IPsec Security 
Association (SA) and local SA database to ensure the OSPF packet 
originated from a source that is trusted for OSPFv3. This is 
required to eliminate the possibility that the packet was 
authenticated using an SA defined for another protocol running on the 
same system. 


The mechanisms in [OSPFV3-AUTH] do not provide protection against 
compromised, malfunctioning, or misconfigured routers. Such routers 
can, either accidentally or deliberately, cause malfunctions 
affecting the whole routing domain. The reader is encouraged to 
consult [GENERIC-THREATS] for a more comprehensive description of 
threats to routing protocols. 


6. Manageability Considerations 


The Management Information Base (MIB) for OSPFv3 is defined in 
[OSPFV3-MIB]. 


7. IANA Considerations 


Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. 
IANA has updated the reference for RFC 2740 to this document. 


Additionally, this document introduces the following IANA 
requirements that were not present in [OSPFV3]: 


o Reserves the options with the values 0x000040 and 0x000080 for 
migrated OSPFv2 options in the OSPFv3 Options registry defined in 
[OSPF-IANA]. For information on the OSPFv3 Options field, refer 
to Appendix A.2. 


o Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix 


Options registry defined in [OSPF-IANA]. For information on 
OSPFv3 Prefix Options, refer to Appendix A.4.1.1. 
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o Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix 
Options registry defined in [OSPF-IANA]. For information on 
OSPFv3 Prefix Options, refer to Appendix A.4.1.1. 


7.1. MOSPF for OSPFv3 Deprecation IANA Considerations 


With the deprecation of MOSPF for OSPFv3, the following code points 
are available for reassignment. Refer to [OSPF-IANA] for information 
on the respective registries. This document: 


o Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options 
registry. 


o Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA 
Function Code registry. 


o Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options 
registry. 


The W-bit in the OSPFv3 Router Properties has also been deprecated. 
This requires a new registry for OSPFv3 router properties since it 
will diverge from the OSPFv2 Router Properties. 


Registry Name: OSPFv3 Router Properties Registry 
Reference: RFC 5340 
Registration Procedures: Standards Action 


Registry: 

Value Description Reference 
0x01 B-bit RFC 5340 
0x02 E-bit RFC 5340 
0x04 V-bit RFC 5340 
0x08 Deprecated RFC 5340 
0x10 Nt-bit RFC 5340 


OSPFv3 Router Properties Registry 
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Appendix A. OSPF Data Formats 


This appendix describes the format of OSPF protocol packets and OSPF 
LSAs. The OSPF protocol runs directly over the IPv6 network layer. 
Before any data formats are described, the details of the OSPF 
encapsulation are explained. 


Next, the OSPF Options field is described. This field describes 
various capabilities that may or may not be supported by pieces of 
the OSPF routing domain. The OSPF Options field is contained in OSPF 
Hello packets, Database Description packets, and OSPF LSAs. 


OSPF packet formats are detailed in Section A.3. 


A description of OSPF LSAs appears in Section A.4. This section 
describes how IPv6 address prefixes are represented within LSAs, 
details the standard LSA header, and then provides formats for each 
of the specific LSA types. 


A.1.  Encapsulation of OSPF Packets 


OSPF runs directly over the IPv6's network layer.  OSPF packets are 
therefore encapsulated solely by IPv6 and local data-link headers. 


OSPF does not define a way to fragment its protocol packets, and 
depends on IPv6 fragmentation when transmitting packets larger than 
the link MTU. If necessary, the length of OSPF packets can be up to 
65,535 bytes. The OSPF packet types that are likely to be large 
(Database Description, Link State Request, Link State Update, and 
Link State Acknowledgment packets) can usually be split into multiple 
protocol packets without loss of functionality. This is recommended; 
IPv6 fragmentation should be avoided whenever possible. Using this 
reasoning, an attempt should be made to limit the size of OSPF 
packets sent over virtual links to 1280 bytes unless Path MTU 
Discovery is being performed [MTUDISC]. 


The other important features of OSPF's IPv6 encapsulation are: 


o Use of IPv6 multicast. Some OSPF messages are multicast when sent 
over broadcast networks. Two distinct IP multicast addresses are 
used. Packets sent to these multicast addresses should never be 
forwarded; they are meant to travel a single hop only. As such, 
the multicast addresses have been chosen with link-local scope and 
packets sent to these addresses should have their IPv6 Hop Limit 
set to 1. b 
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AllSPFRouters 
This multicast address has been assigned the value FF02::5. 
All routers running OSPF should be prepared to receive packets 
sent to this address. Hello packets are always sent to this 
destination. Also, certain OSPF protocol packets are sent to 
this address during the flooding procedure. 


AllDRouters 
This multicast address has been assigned the value FF02::6. 
Both the Designated Router and Backup Designated Router must be 
prepared to receive packets destined to this address. Certain 
OSPF protocol packets are sent to this address during the 
flooding procedure. 


o OSPF is IP protocol 89. This number SHOULD be inserted in the 
Next Header field of the encapsulating IPv6 header. 


o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that 
OSPF protocol packets are sent with IP precedence set to 
Internetwork Control (B’110’) [IPV4]. If routers in the OSPF 
routing domain map their IPv6 Traffic Class octet to the 
Differentiated Services Code Point (DSCP) as specified in 
[DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP 
set to CS6 (B’110000’), as specified in [SERV-CLASS]. In networks 
supporting this mapping, OSPF packets will be given precedence 
over IPv6 data traffic. 


A.2. The Options Field 


The 24-bit OSPF Options field is present in OSPF Hello packets, 
Database Description packets, and certain LSAs (router-LSAs, network- 
LSAs, inter-area-router-LSAs, and link-LSAs). The Options field 
enables OSPF routers to support (or not support) optional 
capabilities, and to communicate their capability level to other OSPF 
routers. Through this mechanism, routers of differing capabilities 
can be mixed within an OSPF routing domain. 


An option mismatch between routers can cause a variety of behaviors, 
depending on the particular option. Some option mismatches prevent 
neighbor relationships from forming (e.g., the E-bit below); these 
mismatches are discovered through the sending and receiving of Hello 


packets. Some option mismatches prevent particular LSA types from 
being flooded across adjacencies; these are discovered through the 
sending and receiving of Database Description packets. Some option 


mismatches prevent routers from being included in one or more of the 
various routing calculations because of their reduced functionality; 
these mismatches are discovered by examining LSAs. 
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Seven bits of the OSPF Options field have been assigned. Each bit is 
described briefly below. Routers should reset (i.e., clear) 
unrecognized bits in the Options field when sending Hello packets or 
Database Description packets and when originating LSAs. Conversely, 
routers encountering unrecognized Options bits in received Hello 
packets, Database Description packets, or LSAs should ignore the 
unrecognized bits and process the packet or LSA normally. 


1 2 
0 1.2.2 4.5.6 7 8S 9 0.Et 2344596 7.8. 9.0 1 2 :3 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 一 十 一 一 十 
Dopo. dod bebe di ob os [|| | e Le TB ER [EN se) zlvel 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 一 十 一 一 十 
The Options field 
The Options field 
V6-bit 
If this bit is clear, the router/link should be excluded from IPv6 
routing calculations. See Section 4.8 for details. 
E-bit 


This bit describes the way AS-external-LSAs are flooded, as 
described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2]. 


x-Bit 
This bit was previously used by MOSPF (see [MOSPF]), which has 
been deprecated for OSPFv3. The bit should be set to 0 and 
ignored when received. It may be reassigned in the future. 


N-bit 
This bit indicates whether or not the router is attached to an 
NSSA as specified in [NSSA]. 


R-bit 
This bit (the "Router' bit) indicates whether the originator is an 
active router. If the router bit is clear, then routes that 


transit the advertising node cannot be computed. Clearing the 
router bit would be appropriate for a multi-homed host that wants 
to participate in routing, but does not want to forward non- 
locally addressed packets. 


DC-bit 


This bit describes the router's handling of demand circuits, as 
Specified in [DEMAND]. 
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*-bit 
These bits are reserved for migration of OSPFv2 protocol 
extensions. 


A.3. OSPF Packet Formats 


There are five distinct OSPF packet types. All OSPF packet types 
begin with a standard 16-byte header. This header is described 
first. Each packet type is then described in a succeeding section. 
In these sections, each packet’s format is displayed and the packet’s 
component fields are defined. 


All OSPF packet types (other than the OSPF Hello packets) deal with 
lists of LSAs. For example, Link State Update packets implement the 
flooding of LSAs throughout the OSPF routing domain. The format of 
LSAs is described in Section A.4. 


The receive processing of OSPF packets is detailed in Section 4.2.2. 
The sending of OSPF packets is explained in Section 4.2.1. 


A.3.1. The OSPF Packet Header 


Every OSPF packet starts with a standard 16-byte header. Together 
with the encapsulating IPv6 headers, the OSPF header contains all the 
information necessary to determine whether the packet should be 
accepted for further processing. This determination is described in 
Section 4.2.2. 
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0 1.2 34 50607 8 9 0.1.2 3 4.5.6.7 8 9 0 1 2 3) 4 5 6.7.8 9 0. 1 
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| Version # | Type | Packet length 
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| Router ID | 
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| Area ID | 
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| Checksum Instance ID 0 
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十 


The OSPF Packet Header 
Version # 


The OSPF version number. This specification documents version 3 
of the OSPF protocol. 
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Type 
The OSPF packet types are as follows. See Appendix A.3.2 through 
Appendix A.3.6 for details. 


1 Hello 

2: Database Description 

3 Link State Request 

4 Link State Update 

5 Link State Acknowledgment 


Packet length 
The length of the OSPF protocol packet in bytes. This length 
includes the standard OSPF header. 


Router ID 
The Router ID of the packet’s source. 


Area ID 
A 32-bit number identifying the area to which this packet belongs. 
All OSPF packets are associated with a single area. Most travel a 
single hop only. Packets traversing a virtual link are labeled 
with the backbone Area ID of 0. 


Checksum 
OSPF uses the standard checksum calculation for IPv6 applications: 
The 16-bit one’s complement of the one’s complement sum of the 
entire contents of the packet, starting with the OSPF packet 
header, and prepending a "pseudo-header" of IPv6 header fields, as 
Specified in Section 8.1 of [IPV6]. The "Upper-Layer Packet 
Length" in the pseudo-header is set to the value of the OSPF 
packet header's length field. The Next Header value used in the 
pseudo-header is 89. If the packet's length is not an integral 
number of 16-bit words, the packet is padded with a byte of zero 
before checksumming. Before computing the checksum, the checksum 
field in the OSPF packet header is set to 0. 


Instance ID 
Enables multiple instances of OSPF to be run over a single link. 
Each protocol instance would be assigned a separate Instance ID; 
the Instance ID has link-local significance only. Received 
packets whose Instance ID is not equal to the receiving 
interface's Instance ID are discarded. 
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These fields are reserved. They SHOULD be set to 0 when sending 
protocol packets and MUST be ignored when receiving protocol 
packets. 


A.3.2. The Hello Packet 


Hello packets are OSPF packet type 1. These packets are sent 
periodically on all interfaces (including virtual links) in order to 
establish and maintain neighbor relationships. In addition, Hello 
packets are multicast on those links having a multicast or broadcast 
capability, enabling dynamic discovery of neighboring routers. 


All routers connected to a common link must agree on certain 
parameters (HelloInterval and RouterDeadInterval). These parameters 
are included in Hello packets allowing differences to inhibit the 
forming of neighbor relationships. The Hello packet also contains 
fields used in Designated Router election (Designated Router ID and 
Backup Designated Router ID), and fields used to detect bidirectional 
communication (the Router IDs of all neighbors whose Hellos have been 
recently received). 
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Interface ID 
32-bit number uniquely identifying this interface among the 


collection of this router’s interfaces. For example, in some 
implementations it may be possible to use the MIB-II IfIndex 
([INTFMIB]). 


Rtr Priority 
This router's Router Priority. Used in (Backup) Designated Router 
election. If set to 0, the router will be ineligible to become 
(Backup) Designated Router. 


Options 
The optional capabilities supported by the router, as documented 
in Section A.2. 


HelloInterval 
The number of seconds between this router's Hello packets. 


RouterDeadInterval 
The number of seconds before declaring a silent router down. 


Designated Router ID 
The sending router's view of the identity of the Designated Router 
for this network. The Designated Router is identified by its 
Router ID. It is set to 0.0.0.0 if there is no Designated Router. 


Backup Designated Router ID 
The sending router's view of the identity of the Backup Designated 
Router for this network. The Backup Designated Router is 
identified by its IP Router ID. It is set to 0.0.0.0 if there is 
no Backup Designated Router. 


Neighbor ID 
The Router IDs of each router on the network with neighbor state 
l-Way or greater. 


A.3.3. The Database Description Packet 


Database Description packets are OSPF packet type 2. These packets 
are exchanged when an adjacency is being initialized. They describe 
the contents of the link-state database. Multiple packets may be 
used to describe the database. For this purpose, a poll-response 
procedure is used. One of the routers is designated to be the master 
and the other is the slave. The master sends Database Description 
packets (polls) that are acknowledged by Database Description packets 
sent by the slave (responses). The responses are linked to the polls 
via the packets' DD sequence numbers. 
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The OSPF Database Description Packet 


The format of the Database Description packet is very similar to both 
the Link State Request packet and the Link State Acknowledgment 
packet. The main part of all three is a list of items, each item 


describing a piece of the link-state database. 


The sending of 


Database Description packets is documented in Section 10.8 of 
[OSPFV2]. The reception of Database Description packets is 
documented in Section 10.6 of [OSPFV2]. 


Options 


The optional capabilities supported by the router, as documented 


in Section A.2. 


Interface MTU 


The size in bytes of the largest IPv6 datagram that can be sent 
out the associated interface without fragmentation. The MTUs of 
common Internet link types can be found in Table 7-1 of [MTUDISC]. 
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Interface MTU should be set to 0 in Database Description packets 
sent over virtual links. 


I-bit 
The Init bit. When set to 1, this packet is the first in the 
sequence of Database Description packets. 


M-bit 
The More bit. When set to 1, it indicates that more Database 
Description packets are to follow. 


MS-bit 
The Master/Slave bit. When set to 1, it indicates that the router 
is the master during the Database Exchange process. Otherwise, 


the router is the slave. 


DD sequence number 
Used to sequence the collection of Database Description packets. 
The initial value (indicated by the Init bit being set) should be 


unique. The DD sequence number then increments until the complete 
database for both the master and slave routers have been 
exchanged. 


The rest of the packet consists of a (possibly partial) list of the 
link-state database's pieces. Each LSA in the database is described 
by its LSA header. The LSA header is documented in Appendix A.4.2. 
It contains all the information required to uniquely identify both 
the LSA and the LSA's current instance. 


A.3.4. The Link State Request Packet 


Link State Request packets are OSPF packet type 3. After exchanging 
Database Description packets with a neighboring router, a router may 
find that parts of its link-state database are out-of-date. The Link 
State Request packet is used to request the pieces of the neighbor's 
database that are more up-to-date. Multiple Link State Request 
packets may need to be used. 


A router that sends a Link State Request packet has in mind the 
precise instance of the database pieces it is requesting. Each 
instance is defined by its LS sequence number, LS checksum, and LS 
age, although these fields are not specified in the Link State 
Request packet itself. The router may receive even more recent LSA 
instances in response. 


The sending of Link State Request packets is documented in Section 


10.9 of [OSPFV2]. The reception of Link State Request packets is 
documented in Section 10.7 of [OSPFV2]. 
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The OSPF Link State Request Packet 


Each LSA requested is specified by its LS type, Link State ID, and 
Advertising Router. This uniquely identifies the LSA without 
specifying its instance. Link State Request packets are understood 
to be requests for the most recent instance of the specified LSAs. 


A.3.5. The Link State Update Packet 


Link State Update packets are OSPF packet type 4. These packets 
implement the flooding of LSAs. Each Link State Update packet 
carries a collection of LSAs one hop further from their origin. 
Several LSAs may be included in a single packet. 


Link State Update packets are multicast on those physical networks 
that support multicast/broadcast. In order to make the flooding 
procedure reliable, flooded LSAs are acknowledged in Link State 
Acknowledgment packets. If retransmission of certain LSAs is 
necessary, the retransmitted LSAs are always carried by unicast Link 
State Update packets. For more information on the reliable flooding 
of LSAs, consult Section 4.5. 
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The OSPF Link State Update Packet 


# LSAs 
The number of LSAs included in this update. 


The body of the Link State Update packet consists of a list of LSAs. 
Each LSA begins with a common 20-byte header, described in 

Appendix A.4.2. Detailed formats of the different types of LSAs are 
described Appendix A.4. 


A.3.6. The Link State Acknowledgment Packet 


Link State Acknowledgment packets are OSPF packet type 5. To make 
the flooding of LSAs reliable, flooded LSAs are explicitly or 
implicitly acknowledged. Explicit acknowledgment is accomplished 
through the sending and receiving of Link State Acknowledgment 
packets. The sending of Link State Acknowledgment packets is 
documented in Section 13.5 of [OSPFV2]. The reception of Link State 
Acknowledgment packets is documented in Section 13.7 of [OSPFV2]. 


Multiple LSAs MAY be acknowledged in a single Link State 
Acknowledgment packet. Depending on the state of the sending 
interface and the sender of the corresponding Link State Update 
packet, a Link State Acknowledgment packet is sent to the multicast 
address AllSPFRouters, the multicast address AllDRouters, or to a 
neighbor's unicast address (see Section 13.5 of [OSPFV2] for 
details). 
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The format of this packet is similar to that of the Data Description 
packet. The body of both packets is simply a list of LSA headers. 
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The OSPF Link State Acknowledgment Packet 


Each acknowledged LSA is described by its LSA header. The LSA header 


is documented in Appendix A.4.2. It contains all the information 
required to uniquely identify both the LSA and the LSA’s current 
instance. 


A.4. LSA Formats 


This document defines eight distinct types of LSAs. Each LSA begins 
with a standard 20-byte LSA header. This header is explained in 
Appendix A.4.2.  Succeeding sections describe each LSA type 
individually. 


Each LSA describes a piece of the OSPF routing domain. Every router 
originates a router-LSA. A network-LSA is advertised for each link 
by its Designated Router. A router's link-local addresses are 
advertised to its neighbors in link-LSAs.  IPv6 prefixes are 
advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS- 
external-LSAs, and NSSA-LSAs. Location of specific routers can be 
advertised across area boundaries in inter-area-router-LSAs. All 
LSAs are then flooded throughout the OSPF routing domain. The 
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flooding algorithm is reliable, ensuring that all routers common to a 
flooding scope have the same collection of LSAs associated with that 
flooding scope. (See Section 4.5 for more information concerning the 
flooding algorithm.) This collection of LSAs is called the link- 
state database. 


From the link-state database, each router constructs a shortest-path 
tree with itself as root. This yields a routing table (see Section 
11 of [OSPFV2]). For details on the routing table build process, see 
Section 4.8. 


A.4.1. IPv6 Prefix Representation 


IPv6 addresses are bit strings of length 128.  IPv6 routing 
protocols, and OSPF for IPv6 in particular, advertise IPv6 address 
prefixes.  IPv6 address prefixes are bit strings whose length ranges 
between 0 and 128 bits (inclusive). 


Within OSPF, IPv6 address prefixes are always represented by a 
combination of three fields: PrefixLength, PrefixOptions, and Address 
Prefix.  PrefixLength is the length in bits of the prefix. 
PrefixOptions is an 8-bit field describing various capabilities 
associated with the prefix (see Appendix A.4.1.1). Address Prefix is 
an encoding of the prefix itself as an even multiple of 32-bit words, 
padding with zero bits as necessary. This encoding consumes 
((PrefixLength + 31) / 32) 32-bit words. 


The default route is represented by a prefix of length 0. 


Examples of IPv6 Prefix representation in OSPF can be found in 
Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and 
Appendix A.4.10. 


A.4.1.1. Prefix Options 


Each prefix is advertised along with an 8-bit field of capabilities. 
These serve as input to the various routing calculations. For 
example, they can indicate that prefixes are to be ignored in some 
cases or are to be marked as not readvertisable in others. 
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The PrefixOptions Field 
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NU-bit 
The "no unicast" capability bit. If set, the prefix should be 
excluded from IPv6 unicast calculations. If not set, it should be 
included. 

LA-bit 


The "local address" capability bit. If set, the prefix is 
actually an IPv6 interface address of the Advertising Router. 
Advertisement of local interface addresses is described in 
Section 4.4.3.9. An implementation MAY also set the LA-bit for 
prefixes advertised with a host PrefixLength (128). 


x-bit 
This bit was previously defined as a "multicast" capability bit. 
However, the use was never adequately specified and has been 
deprecated for OSPFv3. The bit should be set to 0 and ignored 
when received. It may be reassigned in the future. 


P-bit 
The "propagate" bit. Set on NSSA area prefixes that should be 
readvertised by the translating NSSA area border [NSSA]. 


DN-bit 
This bit controls an inter-area-prefix-LSAs or AS-external-LSAs 
re-advertisement in a VPN environment as specified in [DN-BIT]. 


A.4.2. The LSA Header 


All LSAs begin with a common 20-byte header. This header contains 
enough information to uniquely identify the LSA (LS type, Link State 


ID, and Advertising Router). Multiple instances of the LSA may exist 
in the routing domain at the same time. It is then necessary to 
determine which instance is more recent. This is accomplished by 


examining the LS age, LS sequence number, and LS checksum fields that 
are also contained in the LSA header. 
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| LS Age | LS Type | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Link State ID | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| Advertising Router 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Sequence Number 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Checksum | Length | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The LSA Header 


LS Age 


LS 


The time in seconds since the LSA was originated. 


Type 

The LS type field indicates the function performed by the LSA. 
The high-order three bits of LS type encode generic properties of 
the LSA, while the remainder (called LSA function code) indicate 
the LSA’s specific functionality. See Appendix A.4.2.1 for a 
detailed description of LS type. 


Link State ID 


The originating router’s identifier for the LSA. The combination 
of the Link State ID, LS type, and Advertising Router uniquely 
identify the LSA in the link-state database. 


Advertising Router 


LS 


LS 


The Router ID of the router that originated the LSA. For example, 
in network-LSAs this field is equal to the Router ID of the 
network’s Designated Router. 


sequence number 

Successive instances of an LSA are given successive LS sequence 
numbers. The sequence number can be used to detect old or 
duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more 
details. 


checksum 

The Fletcher checksum of the complete contents of the LSA, 
including the LSA header but excluding the LS age field. See 
Section 12.1.7 in [OSPFV2] for more details. 
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length 
The length in bytes of the LSA. This includes the 20-byte LSA 
header. 


A.4.2.1. LSA Type 


The LS type field indicates the function performed by the LSA. The 
high-order three bits of LS type encode generic properties of the 
LSA, while the remainder (called LSA function code) indicate the 
LSA’s specific functionality. The format of the LS type is as 
follows: 


Oi ed, 220 (8. -4 25. 060.7. Bo 09.9.00 d -2— 03. 4. 75 
十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 
|u [S2 [st LSA Function Code 
十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 一 一 十 


LSA Type 


The U-bit indicates how the LSA should be handled by a router that 
does not recognize the LSA’s function code. Its values are: 


0 Treat the LSA as if it had link-local flooding scope 
1 Store and flood the LSA as if the type is understood 
U-Bit 


The S1 and S2 bits indicate the flooding scope of the LSA. The 
values are: 


0 0 Link-Local Scoping - Flooded only on originating link 
bx I Area Scoping - Flooded only in originating area 
1 0 AS Scoping - Flooded throughout AS 
du Reserved 
Flooding Scope 
The LSA function codes are defined as follows. The origination and 


processing of these LSA function codes are defined elsewhere in this 
document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was 
previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated 
for OSPFv3. As shown below, each LSA function b code also implies a 
Specific setting for the U, S1, and S2 bits. 
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LSA Function Code LS Type Description 


1 0x2001 Router-LSA 

2 0x2002 Network-LSA 

2 0x2003 Inter-Area-Prefix-LSA 

4 0x2004 Inter-Area-Router-LSA 

5 0x4005 AS-External-LSA 

6 0x2006 Deprecated (may be reassigned) 
7 0x2007 NSSA-LSA 

8 0x0008 Link-LSA 

9 0x2009 Intra-Area-Prefix-LSA 


LSA Function Code 
A.4.3.  Router-LSAs 


Router-LSAs have LS type equal to 0x2001. Each router in an area 
originates one or more router-LSAs. The complete collection of 
router-LSAs originated by the router describe the state and cost of 
the router's interfaces to the area. For details concerning the 
construction of router-LSAs, see Section 4.4.3.2.  Router-LSAs are 
only flooded throughout a single area. 
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0 1 2 3 
Qi 2-3), AG. PS 98:00. 2 3 A- 506 8 9:0 0127-3 04.5776. 7-8; OO X 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Age [o[o[1] 1 | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Link State ID | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Advertising Router 

十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Sequence Number 

十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Checksum | Length | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 |Nt]x|Vv|E|BI Options | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Type | 0 | Metric 

十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Interface ID | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Neighbor Interface ID | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Neighbor Router ID 

十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
De 
| Type 0 Metric 

十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Interface ID | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Neighbor Interface ID | 
十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Neighbor Router ID 

十 一 十 一 十 一 十 一 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Router-LSA Format 


A single router may originate one or more router-LSAs, distinguished 
by their Link State IDs (which are chosen arbitrarily by the 
originating router). The Options field and V, E, and B bits should 
be the same in all router-LSAs from a single originator. However, in 
the case of a mismatch, the values in the LSA with the lowest Link 
State ID take precedence. When more than one router-LSA is received 
from a single router, the links are processed as if concatenated into 
a single LSA. 
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Bit V 
When set, the router is an endpoint of one or more fully adjacent 
virtual links having the described area as transit area (V is for 
virtual link endpoint). 


Bit E 
When set, the router is an AS boundary router (E is for external). 


Bit B 
When set, the router is an area border router (B is for border). 


Bit x 
This bit was previously used by MOSPF (see [MOSPF]) and has been 
deprecated for OSPFv3. The bit should be set to 0 and ignored 
when received. It may be reassigned in the future. 


Bit Nt 
When set, the router is an NSSA border router that is 
unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt 


stands for NSSA translation). Note that such routers have their 
NSSATranslatorRole area configuration parameter set to Always. 
(See [NSSA].) 

Options 


The optional capabilities supported by the router, as documented 
in Appendix A.2. 


The following fields are used to describe each router interface. The 
Type field indicates the kind of interface being described. It may 
be an interface to a transit network, a point-to-point connection to 
another router, or a virtual link. The values of all the other 
fields describing a router interface depend on the interface's Type 
field. 


Type 
The kind of interface being described. One of the following: 


1 Point-to-point connection to another router 
2 Connection to a transit network 

3 Reserved 

4 Virtual link 


Router Link Types 
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Metric 
The cost of using this router interface for outbound traffic. 


Interface ID 
The Interface ID assigned to the interface being described. See 
Section 4.1.2 and Appendix C.3. 


Neighbor Interface ID 
The Interface ID the neighbor router has associated with the link, 
as advertised in the neighbor’s Hello packets. For transit (type 
2) links, the link’s Designated Router is the neighbor described. 
For other link types, the sole adjacent neighbor is described. 


Neighbor Router ID 
The Router ID the of the neighbor router. For transit (type 2) 
links, the link’s Designated Router is the neighbor described. 
For other link types, the sole adjacent neighbor is described. 


For transit (Type 2) links, the combination of Neighbor Interface ID 
and Neighbor Router ID allows the network-LSA for the attached link 
to be found in the link-state database. 


A.4.4.  Network-LSAs 


Network-LSAs have LS type equal to 0x2002. A network-LSA is 
originated for each broadcast and NBMA link in the area that includes 
two or more adjacent routers. The network-LSA is originated by the 
link's Designated Router. The LSA describes all routers attached to 
the link including the Designated Router itself. The LSA's Link 
State ID field is set to the Interface ID that the Designated Router 
has been advertising in Hello packets on the link. 


The distance from the network to all attached routers is zero. This 
is why the Metric fields need not be specified in the network-LSA. 
For details concerning the construction of network-LSAs, see 

Section 4.4.3.3. 
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A. 


4. 


0 1 2 3 
0123456789 0123456789012345678901 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Age |o|o|1| 2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Link State ID | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| Advertising Router 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Sequence Number 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Checksum | Length | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 Options | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Attached Router | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Network-LSA Format 


Attached Router 
The Router IDs of each of the routers attached to the link. 
Actually, only those routers that are fully adjacent to the 
Designated Router are listed. The Designated Router includes 
itself in this list. The number of routers included can be 
deduced from the LSA header’s length field. 


Ss Inter-Area-Prefix-LSAs 


Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are 
the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see 
Section 12.4.3 of [OSPFV2]). Originated by area border routers, they 
describe routes to IPv6 address prefixes that belong to other areas. 
A separate inter-area-prefix-LSA is originated for each IPv6 address 
prefix. For details concerning the construction of inter-area- 
prefix-LSAs, see Section 4.4.3.4. 


For stub areas, inter-area-prefix-LSAs can also be used to describe a 
(per-area) default route. Default summary routes are used in stub 
areas instead of flooding a complete set of external routes. When 
describing a default summary route, the inter-area-prefix-LSA's 
PrefixLength is set to 0. 
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0 1 2 3 
012345678°9012345678°9012345 67890 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| LS Age 1olol|1| 3 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Link State ID | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| Advertising Router 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| LS Sequence Number 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| LS Checksum | Length | 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| 0 | Metric | 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| PrefixLength | PrefixOptions | 0 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Address Prefix | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Inter-Area-Prefix-LSA Format 


Metric 
The cost of this route. Expressed in the same units as the 
interface costs in router-LSAs. When the inter-area-prefix-LSA is 
describing a route to a range of addresses (see Appendix C.2), the 
cost is set to the maximum cost to any reachable component of the 
address range. 


PrefixLength, PrefixOptions, and Address Prefix 
Representation of the IPv6 address prefix, as described in 
Appendix A.4.1. 


A.4.6.  Inter-Area-Router-LSAs 


Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are 
the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see 
Section 12.4.3 of [OSPFV2]). Originated by area border routers, they 
describe routes to AS boundary routers in other areas. To see why it 
is necessary to advertise the location of each ASBR, consult Section 
16.4 in [OSPFV2]. Each LSA describes a route to a single router. 

For details concerning the construction of inter-area-router-LSAs, 
see Section 4.4.3.5. 
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Inter-Area-Router-LSA Format 


Options 
The optional capabilities supported by the router, as documented 
in Appendix A.2. 


Metric 
The cost of this route. Expressed in the same units as the 
interface costs in router-LSAs. 


Destination Router ID 
The Router ID of the router being described by the LSA. 


A.4.7.  AS-External-LSAs 


AS-external-LSAs have LS type equal to 0x4005. These LSAs are 
originated by AS boundary routers and describe destinations external 
to the AS. Each LSA describes a route to a single IPv6 address 
prefix. For details concerning the construction of AS-external-LSAs, 
see Section 4.4.3.6. 


AS-external-LSAs can be used to describe a default route. Default 
routes are used when no specific route exists to the destination. 
When describing a default route, the AS-external-LSA's PrefixLength 
is set to 0. 
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Metric 
The cost of this route. Interpretation depends on the external 
type indication (bit E above). 


PrefixLength, PrefixOptions, and Address Prefix 
Representation of the IPv6 address prefix, as described in 
Appendix A.4.1. 


Referenced LS Type 
If non-zero, an LSA with this LS type is to be associated with 
this LSA (see Referenced Link State ID below). 


Forwarding address 
A fully qualified IPv6 address (128 bits). Included in the LSA if 
and only if bit F has been set. If included, data traffic for the 
advertised destination will be forwarded to this address. It MUST 
NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an 
IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are 
normally installed with link-local addresses, an OSPFv3 
implementation advertising a forwarding address MUST advertise a 
global IPv6 address. This global IPv6 address may be the next-hop 
gateway for an external prefix or may be obtained through some 
other method (e.g., configuration). 


External Route Tag 
A 32-bit field that MAY be used to communicate additional 
information between AS boundary routers. Included in the LSA if 
and only if bit T has been set. 


Referenced Link State ID 
Included if and only if Reference LS Type is non-zero. If 
included, additional information concerning the advertised 
external route can be found in the LSA having LS type equal to 
"Referenced LS Type", Link State ID equal to "Referenced Link 
State ID", and Advertising Router the same as that specified in 
the AS-external-LSA's link-state header. This additional 
information is not used by the OSPF protocol itself. It may be 


used to communicate information between AS boundary routers. The 
precise nature of such information is outside the scope of this 
Specification. 


All, none, or some of the fields labeled Forwarding address, External 
Route Tag, and Referenced Link State ID MAY be present in the AS- 
external-LSA (as indicated by the setting of bit F, bit T, and 
Referenced LS Type respectively). When present, Forwarding Address 
always comes first, External Route Tag next, and the Referenced Link 
State ID last. 
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A.4.8. NSSA-LSAs 


NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by 
AS boundary routers within an NSSA and describe destinations external 
to the AS that may or may not be propagated outside the NSSA (refer 
to [NSSA]). Other than the LS type, their format is exactly the same 
as AS-external LSAs as described in Appendix A.4.7. 


A global IPv6 address MUST be selected as forwarding address for 
NSSA-LSAs that are to be propagated by NSSA area border routers. The 
selection should proceed the same as OSPFv2 NSSA support [NSSA] with 
additional checking to ensure IPv6 link-local address are not 
selected. 


A.4.9.  Link-LSAs 


Link-LSAs have LS type equal to 0x0008. A router originates a 
separate link-LSA for each attached physical link. These LSAs have 
link-local flooding scope; they are never flooded beyond the 
associated link.  Link-LSAs have three purposes: 


1. They provide the router's link-local address to all other routers 
attached to the link. 


2. They inform other routers attached to the link of a list of IPv6 
prefixes to associate with the link. 


3. They allow the router to advertise a collection of Options bits 
in the network-LSA originated by the Designated Router on a 
broadcast or NBMA link. 


For details concerning the construction of links-LSAs, see 
Section 4.4.3.8. 


A link-LSA's Link State ID is set equal to the originating router's 
Interface ID on the link. 
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Rtr Priority 
The Router Priority of the interface attaching the originating 
router to the link. 


Options 
The set of Options bits that the router would like set in the 
network-LSA that will be originated by the Designated Router on 
broadcast or NBMA links. 
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Link-local Interface Address 
The originating router’s link-local interface address on the link. 


# prefixes 
The number of IPv6 address prefixes contained in the LSA. 


The rest of the link-LSA contains a list of IPv6 prefixes to be 
associated with the link. 


PrefixLength, PrefixOptions, and Address Prefix 
Representation of an IPv6 address prefix, as described in 
Appendix A.4.1. 


A.4.10. Intra-Area-Prefix-LSAs 


Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses 
intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes 
that are associated with a local router address, an attached stub 
network segment, or an attached transit network segment. In IPv4, 
the first two were accomplished via the router's router-LSA and the 
last via a network-LSA. In OSPF for IPv6, all addressing information 
that was advertised in router-LSAs and network-LSAs has been removed 
and is now advertised in intra-area-prefix-LSAs. For details 
concerning the construction of intra-area-prefix-LSA, see 

Section 4.4.3.9. 


A router can originate multiple intra-area-prefix-LSAs for each 


router or transit network. Each such LSA is distinguished by its 
unique Link State ID. 
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| LS Checksum | Length | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| # Prefixes | Referenced LS Type | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| Referenced Link State ID 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| Referenced Advertising Router 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| PrefixLength | PrefixOptions | Metric 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Address Prefix 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| PrefixLength | PrefixOptions Metric 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Address Prefix | 
十 一 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Intra-Area-Prefix LSA Format 


# prefixes 
The number of IPv6 address prefixes contained in the LSA. 


Referenced LS Type, Referenced Link State ID, and Referenced 
Advertising Router 
Identifies the router-LSA or network-LSA with which the IPv6 
address prefixes should be associated. If Referenced LS Type is 
0x2001, the prefixes are associated with a router-LSA, Referenced 
Link State ID should be 0, and Referenced Advertising Router 
should be the originating router’s Router ID. If Referenced LS 
Type is 0x2002, the prefixes are associated with a network-LSA, 
Referenced Link State ID should be the Interface ID of the link's 
Designated Router, and Referenced Advertising Router should be the 
Designated Router's Router ID. 
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The rest of the intra-area-prefix-LSA contains a list of IPv6 
prefixes to be associated with the router or transit link, as well as 
their associated costs. 


PrefixLength, PrefixOptions, and Address Prefix 
Representation of an IPv6 address prefix, as described in 
Appendix A.4.1. 


Metric 
The cost of this prefix.  Expressed in the same units as the 
interface costs in router-LSAs. 


Appendix B. Architectural Constants 


Architectural constants for the OSPF protocol are defined in Appendix 
B of [OSPFV2]. The only difference for OSPF for IPv6 is that 
DefaultDestination is encoded as a prefix with length 0 (see 

Appendix A.4.1). 


Appendix C. Configurable Constants 


The OSPF protocol has quite a few configurable parameters. These 
parameters are listed below. They are grouped into general 
functional categories (area parameters, interface parameters, etc.). 
Sample values are given for some of the parameters. 


Some parameter settings need to be consistent among groups of 
routers. For example, all routers in an area must agree on that 
area's parameters. Similarly, all routers attached to a network must 
agree on that network's HelloInterval and RouterDeadInterval. 


Some parameters may be determined by router algorithms outside of 
this specification (e.g., the address of a host connected to the 
router via a SLIP line). From OSPF's point of view, these items are 
still configurable. 


C.1. Global Parameters 
In general, a separate copy of the OSPF protocol is run for each 
area. Because of this, most configuration parameters are defined on 


a per-area basis. The few global configuration parameters are listed 
below. 
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Router ID 
This is a 32-bit number that uniquely identifies the router in the 
Autonomous System. If a router’s OSPF Router ID is changed, the 
router’s OSPF software should be restarted before the new Router 
ID takes effect. Before restarting due to a Router ID change, the 
router should flush its self-originated LSAs from the routing 
domain (see Section 14.1 of [OSPFV2]). Otherwise, they will 
persist for up to MaxAge seconds. 


Because the size of the Router ID is smaller than an IPv6 address, it 
cannot be set to one of the router's IPv6 addresses (as is commonly 
done for IPv4). Possible Router ID assignment procedures for IPv6 
include: a) assign the IPv6 Router ID as one of the router's IPv4 
addresses or b) assign IPv6 Router IDs through some local 
administrative procedure (similar to procedures used by manufacturers 
to assign product serial numbers). 


The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. 
C.2. Area Parameters 


All routers belonging to an area must agree on that area's 
configuration. Disagreements between two routers will lead to an 
inability for adjacencies to form between them, with a resulting 
hindrance to the flow of both routing protocol information and data 
traffic. The following items must be configured for an area: 


Area ID 
This is a 32-bit number that identifies the area. The Area ID of 
0 is reserved for the backbone. 


List of address ranges 
Address ranges control the advertisement of routes across area 
boundaries. Each address range consists of the following items: 


[IPv6 prefix, prefix length] 
Describes the collection of IPv6 addresses contained in the 
address range. 


Status 
Set to either Advertise or DoNotAdvertise. Routing information 
is condensed at area boundaries. External to the area, at most 
a single route is advertised (via a inter-area-prefix-LSA) for 
each address range. The route is advertised if and only if the 
address range's Status is set to Advertise.  Unadvertised 
ranges allow the existence of certain networks to be 
intentionally hidden from other areas. Status is set to 
Advertise by default. 
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ExternalRoutingCapability 
Whether AS-external-LSAs will be flooded into/throughout the area. 
If AS-external-LSAs are excluded from the area, the area is called 
a stub area or NSSA. Internal to stub areas, routing to external 
destinations will be based solely on a default inter-area route. 
The backbone cannot be configured as a stub or NSSA area. Also, 
virtual links cannot be configured through stub or NSSA areas. 
For more information, see Section 3.6 of [OSPFV2] and [NSSA]. 


StubDefaultCost 
If the area has been configured as a stub area, and the router 
itself is an area border router, then the StubDefaultCost 
indicates the cost of the default inter-area-prefix-LSA that the 
router should advertise into the area. See Section 12.4.3.1 of 
[OSPFV2] for more information. 


NSSATranslatorRole and TranslatorStabilityInterval 
These area parameters are described in Appendix D of [NSSA]. 
Additionally, an NSSA Area Border Router (ABR) is also required to 
allow configuration of whether or not an NSSA default route is 
advertised in an NSSA-LSA. If advertised, its metric and metric 
type are configurable. These requirements are also described in 
Appendix D of [NSSA]. 


ImportSummaries 
When set to enabled, prefixes external to the area are imported 
into the area via the advertisement of inter-area-prefix-LSAs. 
When set to disabled, inter-area routes are not imported into the 
area. The default setting is enabled. This parameter is only 
valid for stub or NSSA areas. 


(BE Router Interface Parameters 


Some of the configurable router interface parameters (such as Area 
ID, HelloInterval, and RouterDeadInterval) actually imply properties 
of the attached links. Therefore, these parameters must be 
consistent across all the routers attached to that link. The 
parameters that must be configured for a router interface are: 


IPv6 link-local address 
The IPv6 link-local address associated with this interface. May 
be learned through auto-configuration. 
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Area ID 
The OSPF area to which the attached link belongs. 


Instance ID 


The OSPF protocol instance associated with this OSPF interface. 
Defaults to 0. 


Interface ID 
32-bit number uniquely identifying this interface among the 


collection of this router’s interfaces. For example, in some 
implementations it may be possible to use the MIB-II IfIndex 
([INTFMIB]). 


IPv6 prefixes 
The list of IPv6 prefixes to associate with the link. These will 
be advertised in intra-area-prefix-LSAs. 


Interface output cost(s) 
The cost of sending a packet on the interface, expressed in the 
link-state metric. This is advertised as the link cost for this 
interface in the router's router-LSA. The interface output cost 
MUST always be greater than 0. 


RxmtInterval 
The number of seconds between LSA retransmissions for adjacencies 
belonging to this interface. Also used when retransmitting 
Database Description and Link State Request packets. This should 
be well over the expected round-trip delay between any two routers 
on the attached link. The setting of this value should be 
conservative or needless retransmissions will result. Sample 
value for a local area network: 5 seconds. 


InfTransDelay 
The estimated number of seconds it takes to transmit a Link State 
Update packet over this interface.  LSAs contained in the update 
packet must have their age incremented by this amount before 
transmission. This value should take into account the 
transmission and propagation delays of the interface. It MUST be 
greater than 0. Sample value for a local area network: 1 second. 


Router Priority 
An 8-bit unsigned integer. When two routers attached to a network 
both attempt to become the Designated Router, the one with the 
highest Router Priority takes precedence. If there is still a 
tie, the router with the highest Router ID takes precedence. A 
router whose Router Priority is set to 0 is ineligible to become 
the Designated Router on the attached link. Router Priority is 
only configured for interfaces to broadcast and NBMA networks. 
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HelloInterval 
The length of time, in seconds, between Hello packets that the 
router sends on the interface. This value is advertised in the 
router's Hello packets. It MUST be the same for all routers 
attached to a common link. The smaller the HelloInterval, the 
faster topological changes will be detected. However, more OSPF 


routing protocol traffic will ensue. Sample value for a X.25 PDN: 
30 seconds. Sample value for a local area network (LAN): 10 
seconds. 


RouterDeadInterval 
After ceasing to hear a router's Hello packets, the number of 
seconds before its neighbors declare the router down. This is 
also advertised in the router's Hello packets in their 
RouterDeadInterval field. This should be some multiple of the 
HelloInterval (e.g., 4). This value again MUST be the same for 
all routers attached to a common link. 


LinkLSASuppression 
Indicates whether or not origination of a link-LSA is suppressed. 
If set to "enabled" and the interface type is not broadcast or 
NBMA, the router will not originate a link-LSA for the link. This 
implies that other routers on the link will ascertain the router's 
next-hop address using a mechanism other than the link-LSA (see 
Section 4.8.2). The default value is "disabled" for interface 
types described in this specification. It is implicitly 
"disabled" if the interface type is broadcast or NBMA. Future 
interface types MAY specify a different default. 


C.4. Virtual Link Parameters 


Virtual links are used to restore/increase connectivity of the 
backbone. Virtual links may be configured between any pair of area 
border routers having interfaces to a common (non-backbone) area. 

The virtual link appears as a point-to-point link with no global IPv6 
addresses in the graph for the backbone. The virtual link must be 
configured in both of the area border routers. 


A virtual link appears in router-LSAs (for the backbone) as if it 
were a separate router interface to the backbone. As such, it has 
most of the parameters associated with a router interface (see 
Appendix C.3). Virtual links do not have link-local addresses, but 
instead use one of the router's global-scope IPv6 addresses as the IP 
Source in OSPF protocol packets it sends on the virtual link. Router 
Priority is not used on virtual links. Interface output cost is not 
configured on virtual links, but is dynamically set to be the cost of 
the transit area intra-area path between the two endpoint routers. 
The parameter RxmtInterval may be configured and should be well over 
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the expected round-trip delay between the two routers. This may be 
hard to estimate for a virtual link; it is better to err on the side 
of making it too long. 


A virtual link is defined by the following two configurable 
parameters: the Router ID of the virtual link’s other endpoint and 
the (non-backbone) area that the virtual link traverses (referred to 
as the virtual link’s transit area). Virtual links cannot be 
configured through stub or NSSA areas. Additionally, an Instance ID 
may be configured for virtual links from different protocol instances 
in order to utilize the same transit area (without requiring 
different Router IDs for demultiplexing). 


C.5. NBMA Network Parameters 


OSPF treats an NBMA network much like it treats a broadcast network. 
Since there may be many routers attached to the network, a Designated 
Router is selected for the network. This Designated Router then 
originates a network-LSA listing all routers attached to the NBMA 
network. 


However, due to the lack of broadcast capabilities, it may be 
necessary to use configuration parameters in the Designated Router 
selection. These parameters will only need to be configured in those 
routers that are themselves eligible to become the Designated Router 
(i.e., those routers whose Router Priority for the network is non- 
zero), and then only if no automatic procedure for discovering 
neighbors exists: 


List of all other attached routers 
The list of all other routers attached to the NBMA network. Each 
router is configured with its Router ID and IPv6 link-local 
address on the network. Also, for each router listed, that 
router's eligibility to become the Designated Router must be 
defined. When an interface to an NBMA network first comes up, the 
router only sends Hello packets to those neighbors eligible to 
become the Designated Router until such time that a Designated 
Router is elected. 


PollInterval 
If a neighboring router has become inactive (Hello packets have 
not been seen for RouterDeadInterval seconds), it may still be 
necessary to send Hello packets to the dead neighbor. These Hello 
packets will be sent at the reduced rate PollInterval, which 
should be much larger than HelloInterval. Sample value for a PDN 
X.25 network: 2 minutes. 
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C.6. Point-to-Multipoint Network Parameters 


On point-to-multipoint networks, it may be necessary to configure the 
set of neighbors that are directly reachable over the point-to- 
multipoint network. Each neighbor is configured with its Router ID 
and IPv6 link-local address on the network. Designated Routers are 
not elected on point-to-multipoint networks, so the Designated Router 
eligibility of configured neighbors is not defined. 


Qa Host Route Parameters 


Host prefixes are advertised in intra-area-prefix-LSAs. They 
indicate either local router addresses, router interfaces to point- 
to-point networks, looped router interfaces, or IPv6 hosts that are 
directly connected to the router (e.g., via a PPP connection). For 
each host directly connected to the router, the following items must 
be configured: 


Host IPv6 prefix 
An IPv6 prefix belonging to the directly connected host. This 
must not be a valid IPv6 global prefix. 


Cost of link to host 
The cost of sending a packet to the host, in terms of the link- 
state metric. However, since the host probably has only a single 
connection to the Internet, the actual configured cost(s) in many 
cases is unimportant (i.e., will have no effect on routing). 


Area ID 
The OSPF area to which the host's prefix belongs. 
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